Welcome everyone to another episode of That's My JAMstack the podcast where we explore the inner psyche of JAMstackers everywhere asking the simple question, what's your jam in the JAMstack. On today's episode, we talked to Colby Fayock, a senior front end engineer with element 84. But before we dive into the interview, let me shout out to our sponsor take shape. Stick around after the episode to learn more about their content platform or head on over to take shape.io slash That's My JAMstack for more information.
Sure. So I'm a senior front end engineer and UX designer at Element84. For a little bit about us, we focused on bringing remote sensing and Life Sciences data to the cloud. So that's usually like satellite data and health data. But once that's in the cloud, that's kind of where I stepped in and put you eyes in front of that. So some things that I'm working on right now are a dashboard.
For testing a commercial satellite, and we're also working on a mapping interface for helping first responders tackle natural disasters like Wow, so like a big use case for that was working with people who were actually in it for the campfire California wildfires.
Yeah, so I definitely am more on the front end engineering side. It's kind of funny because I started off more on the design side, but as I kind of learned and learn, I've just slowly moved the needle to the engineering side. But that said, I still thoroughly enjoy both aspects of it. And usually I'm still the one doing the wires and such on the projects that we're working on.
But aside from that, you know, I, I do really enjoy coding, but probably spent too much time watching TV movies. And lately, I've been trying to push myself to write more. So I've been putting a lot of articles up on Free Code Camp. And that actually inspired me from a co worker who kind of gave me the idea that, you know, there's a lot of ways to look at different articles, right, rather than I kind of had that imposter syndrome. But I'm able to get past that. And it's been successful. So far,
I'm a firm believer that anyone who's writing code can benefit from their own blog in the future. Like if you're if you're writing and you saw the problem, write about it, and then you Google it down the road, and you'll be the response.
Nice. Very cool. So let's talk about the JAMstack a little bit. Obviously, that's what this podcast is all about. What was your entry point into this philosophy of the JAMstack or maybe static sites or wherever you want to call it?
So it's kind of funny because I listened to a couple of the other podcasts and a lot of people seem to be getting into development from the old MySpace days. So when I was in high school, I would do the I would hack over divs on top of the profile, people saw me doing that and I actually made a little bit of a side hustle out of it, redesigning some people's profiles, but from there, you know, just creating Counter Strike Team pages for the teams I was on.
Well, since then, they were bought out by GameStop. But we don't need to get into that. But it was interesting because they weren't a JAMstack site. But we were trying to cash the front, the front end so heavily, where it was just being served statically from fastly. But we redesigned the checkout and basically use the jam site principles of reaching out to their API's and stuff to build that. But it was definitely at the time, since it was still kind of a relatively newer idea for an architecture. It was rough to try to get the convinced that our engineers to support the API's to that fashion because it's traditionally a pearl house. So building out the that's how the pages were typically rendered. Yeah.
So kind of so so from there. What what are you currently working and what are your favorite jams, tech technologies or philosophies? What are you using professionally and personally that sort of thing.
Yeah. So, personally, when I'm bootstrapping sites, I usually just default to Gatsby. And that if I just because it's, it's so easy, you know, static sites are just much easier to manage from a resource perspective, in my opinion. And, you know, it's super cheap and other buzzwords, like infinitely scalable. But as a primary engineer, you know, I don't need to worry about figuring out the server side server side of things. So I just kind of dumped my static assets. I still have like two WordPress clients, but I've since moved them to lightsail, which has made it a little bit easier since it's more managed on the AWS side. And I joke about the buzzwords part of it, but really, that's compelling for from a customer perspective, right? Because being able to use those phrases like infinitely scalable, secure and cheap is just so valuable,
Exactly, and it's a realistic scenario. And even if you have the most complex caching system, things can go wrong. So That's what, that's a big thing of what attracts me to it. But with Element 84, you know, it switches a little bit where we got most of it into s3 instead of using something like natla phi, but we're big AWS house. So JAMstack sites, kind of pulling those five fundamental pillars for AWS, which is like for good software architecture. So it makes it really easy to kind of push that
So I wrote this down because I had a feeling you would ask me. Operational Excellence security, which is a big one, real reliability, performance and cost optimization. So pretty much exactly. It takes the ticks the boxes of every single one of those. Yep.
Very cool. And so what are y'all doing other than obviously, if you're on AWS, you're pretty much jam packed at that point. How is element a for utilizing this kind of separation and how are you doing like mapping and stuff like that in a JAMstack world so interesting.
Maps kind of inherently fit into the whole static site idea. We use a library called leaflet which it attaches itself to a static element inside the DOM. So imagine just a div kind of like you would with a react app, right.
And it just kind of plays from there pulling in the API's for things like matte tiles, and any kind of data you want to visualize on the map. But really, we can build out these applications completely static and pull all those API's and stuff around on the client, just like a, you know, normal JAMstack app.
But it's, it's made it easy to kind of fit it in there. And it's tough with leaflet sometimes because it relies on the window. So if you're kind of building it within a react application, you kind of have to get some past some of those challenges like particularly Gatsby. When you compile, it runs the code, right? So the window is not available. The leaflet library assumes it is and you can run into competition areas with that. So it has its challenges, but it's it's interesting, and it's provided some really powerful stuff. Yeah.
Yeah, it's it's a real problem. And they provide a solution where you kind of set I I don't know what's actually happening, but you set the loaders to know in the in the web pack configuration that resolves it.
Yeah. So I think generally the amount of options that are coming up to just quickly spin things up like I kind of mentioned Gatsby Netlify I'm pretty sold on that combo right now, just because it's made my life so much easier to spin things up where both me and the 14 like we can focus on the things that are different, right? Like we don't have to spend our time bootstrapping the app, creating a custom web pack configuration and all that. So it really makes it lets us focus on things that are different. I advocate a lot for Netlify simply because of those kind of things.
Nice. And where do you kind of fall on, like static rendering on the server versus dynamic stuff, obviously doing mapping stuff, you're doing more stuff in the client? is there is there any way to offload that before built like during the build that you can kind of have the map in place before the client takes over?
Nothing too heavily. We're building a component library based off of the leaflet of just trying to make things a little bit easier for people to interface with it because of some of the problems I mentioned. We're hoping to eventually open source that but you know, the whole, building something and open sourcing is isn't always as straightforward as you might want it to be.
I wrote this down because I wouldn't remember the acronym, its spatial temporal asset catalog. So it's essentially Yes, it's essentially collecting metadata and the imagery along with the satellite imagery and provide it providing in a way that you can actually search on it. So being able to pull up those results, make dynamic searches on those maps is important to be able to help provide these people, like scientists ability to actually look at the data, right? So using tools like that helps us a lot
Cool. And I imagine like when you're talking about scientists, and we're talking about climate stuff, and we're talking about all these like, heavy big sets of data, like how do you how do you deal with that large of a scope in a modular kind of tinier way?
Yeah, so probably our bread and butter with Element 84 is the data processing aspect of it. So that's a completely different component in built in our kind of architecture, where we have our data pipeline that pulls in and processes the data. Then we have a back end team which might be the same people that builds, like one particular instances, Elasticsearch, right putting that in front of the the main metadata repository. At which point for me, it's really just a bunch of API's that I'm able to search on. So coming from a UI perspective, I don't have to worry as much about those complexities. But it is interesting to see the pipeline of data coming through which we rely pretty heavily on Native AWS for goals.
Sure. So I am a huge blink 182 fan from the early days, so I'm still enjoying a lot of their music that they're putting out maybe not as much as some of the earlier stuff but a co workers would probably give me a hard time for saying this, but I still frequently jam out. So come and get it by Selena Gomez.
Yeah, generally I'm writing trying to write a lot. So checking out some of the articles I'm writing but you know, I'm, I feel really strongly about maps and being able to give a lot of power to people with the tools in their hand, right, so scientists and such. So to try and help get things started I created Gatsby starter just gets me started for leaflet. It's pretty much called, which is up on my GitHub. I can also post a link doesn't come with a ton of features yet, but it really allows people to easily spin up mapping application. And the biggest takeaway that I'm trying to push, and it's kind of like Chef Gusto, from Ratatouille where he says anyone could cook, I like to believe that anybody can create a map, right. So just being able to have people easily be able to spin up an app, it might put more power in somebody's hands that they didn't really have before. over the holidays I created based off of that starter, I created a Santa Tracker, which people had a good time with, it was cool being able to see some of my co workers spend time with their kids actually walking through the same santa tracker. so just be able to do fun things like that is powerful, and shows what you can do.
And you completely destroyed my follow up question was just gonna be like, how do I get started in mapping, but so we'll, we'll throw it out that that that Gatsby started for the mapping. Is there any sort of like big hurdles to getting into leaflet or if you've got that starter? You can just kind of go to town with it.
Yeah, I mean, once you get that, sorry, spun up. I have an example in there that it really just kind of zooms in on your current location if you allow it. Otherwise, I think it's D.C. Which is the area that I'm from.
But be able to take that example and apply it with leafless documentation, I think is probably the biggest bet there. And I'm hoping to do more writing on more complex leaflet applications. But generally, I think that's a good starting place.
Cool and I curiosity, you might not have an answer to it. Where, where could somebody go to find maybe some data sets that they could play with, especially around some of these more scientific topics with mapping? Are there any open data sets that they can explore?
Yeah, so NASA, actually, I, at least through their Gibbs program, and I know some of their other programs, they make a ton of data openly available for anybody. So kind of just searching on that is a good way to get your just kind of get rolling in it. I know. There's also some other teams like blanking on the name. They provide some open data for disaster scenarios, which is powerful because they enable people to do things that will help others actually work with some of these disaster scenarios, which is some of the data that we use with the disaster relief efforts we're working on.
Thanks again to Colby for being on the show. And thanks again to you dear listeners for tuning in Week after week, be sure to leichhardt star or what have you in your podcast app of choice. And now it's sponsored time coming back this week is take shape. take shape is a content platform for the JAMstack. They've got a headless CMS, a static site generator and awesome graph. qL API is super simple to get started and to work with and if you're interested, you should head on over to take shape.io slash That's My JAMstack to sign up.