Jamison: Hello friends.
Charles: Aimee Knight.
Aimee: Hello, from Nashville at last.
Charles: I’m Charles Max Wood from Devchat.tv. This week, we have two guests. We have Brian Douglas.
Charles: We have Matt Christensen.
Matt: Hey there.
Charles: Do the two of you want to introduce yourselves really quickly?
Brian: Yeah. Matt you go first.
Matt: Okay, sure. My name is Matt Billman. I’m the founder of Netlify where we are building a modern platform for the kind of episode sites we’re trying to talk about today called JAMStack sites. Netlify is basically a platform for deploying, building, and maintaining modern websites.
Before Netlify I’ve been doing several projects. I was a founder of Webpop. I spent seven years in Spain where I was the CTO of Domestika and build tens of thousands of websites.
Brian: I’ll introduce myself. I’m Brian Douglas. I’m here in the Bay Area, specifically Oakland. I do frontend for Netlify but I’m also a developer advocate, meaning that I just do some more talking and meet up talks. I’m also the host of JAMStack Radio, which is another podcast. A top in this base.
Charles: Awesome. We did bring you on to talk about JAMStack. I think we talked on Google Hangouts or something for a few minutes, I don’t remember. But I think we talked and then we would wind up the call. You explained to me a little bit of what JAMStack is. Do you want to give us that thumbnail picture of what JAMStack is and what it’s about? Because I thought it was an interesting take on building applications.
Five years ago when you talk to a new frontend developer, they would probably be FTPing into a server and working directly on code and things like that. Today, pretty much any frontend developer has some work flow where they use Git as servers in control but also as their mechanism for deploying, and pushing, and pulling, collaborating, and use built tools to compile and watch both usage pipelines but also to a larger degree the built of the actual Markup.
The name itself came about after we had been working a while in this space, in the area of what we would talk about static deployment, static hosting. Always found whenever we talk with anybody in this base that it was like a really weird term for what it was we were doing and what it was this whole new way of building sites was about.
Feeling that holding those kind of sites, static sites, was really weird because this was like, as you said, the latest sites you worked on was probably like a 100,000 of lines of Ruby code. With the whole developer team working on it and doing all kinds of interesting shit like job board in the browser, real time in visualizations of data, and so on.
Jamison: I’m a little confused about what this actually means. Because to me, it sounds like you’re saying instead of talking about you have a backend server and frontend, you have frontend and then you have an API, the API is your backend server. It sounds like you’ve given a name to a thing we’ve been doing for a while. I’m confused how it’s done.
Once I actually work my frontend framework which was Amber, I was building like a Rails API. That always separate between the two repositories. That way, I always had an idea of like I can always host my Rails API on Heroku. But then the question was where do I put my frontend code.
At the time, Devchat was pretty popular so I was actually a pretty active Devchat user before they were merged in the Firebase. I think that’s what we do at Netlify. We take that frontend portion of your app when it’s separate in the two different repositories. We use that and we call that JAMStack. Does that clear it up a little bit?
Jamison: I guess I’m still confused.
On the other hand, in the static site generation community, we’ve just seen hundreds of new static site generators come out. We’ve also seen people build more and more business projects with them like large publications, a sites with a thousands of pages, and interactive filaments and so on.
When we were talking to people, we could see that was actually the same thing happening but there was not a good nomenclature around actually talking about it as the same thing.
I remember Devchat started talking about static apps for example which is like, I have really weird name because you don’t want an app to be static. By definition, it’s something dynamic. When we talk about static sites, we keep running into the same issue as well at people actually building sites with a set of tools that built the Markup up fronts and push it at somewhere but that are not static in any normal sense of the word, they’re actually hyperdynamic.
That’s why between a lot of these people, this term nomenclature I’m talking about the JAMStack instead sort of started rolling out.
Charles: To the question of we’ve been talking to a backend for years. What this does is this eliminates one layer that you have to understand because essentially instead of coming up with the system written in Rails, or Express, or Phoenix, or something else. Building out those APIs that it talks to, you’re talking advantage of APIs that already exist. The exact was given of having Firebase as sort of your backend or you could use something like Parse which is an open source system that you can sync data through or something like that.
Aimee: I’m Googling around here and I just came across some slides. It looks like the three main points so far that I’ve looked at are security, reliability, and performance. Can you talk about those three and why JAMStack is better if you’re concerned with those things?
Matt: Yeah, for sure.
Aimee: I mean, who’s not concerned with those things.
Matt: Most people are. I guess this is also why we’re starting to see so much going on in this area. Security, reliability and performance are all things that have become a larger and larger issue for the traditional way of building especially websites especially when you talk about things like WordPress and Drupal and so on, where you have this traditional monolithic approach where you have something like constant driven site but every time someone visits that site you actually interact with a running program that has to build up that site and send it back to you.
That way of working has meant that the web has scaled. Some of you might still know the term of being slashdotted which is like the old term for getting on a social news network and then traffic crashes your server. Slashdot, the amount of traffic that would send years ago was just miniscule compared to what modern social networks can send in terms of traffic.
That also means that just to run a normal site that might someday get a traffic spike, you have to implement layers and layers of caching. It makes publication difficult, it makes maintenance difficult, and introduce a lot of complexity. That complexity in itself introduces a lot of security holes. I saw in Netcraft last year I think it showed that around 70% of full work per sites are vulnerable to known exploits.
Drupal had this famous, Drupal couple apps a while ago whether was a security exploit that the core team announce that if you hadn’t updated after they announce the update within seven hours, you should consider your whole server hacked and rebuild everything. That affected millions of millions of sites.
Of course, if you can take an approach where you try to minimize any interaction with the running program during the visits to a site, you make their surface area for security exploits much, much smaller. If you can pre-build as much of your site upfront and decouple the build process from the actual process of running or hosting the site, then you eliminate almost all normal security issues.
You’ll probably still have some parts of your site where you need something that you can’t rebuild upfront for all the dynamic elements. Again, if you can isolate that into much smaller special purpose APIs, then you can delegate a lot of the maintenance and hosting to the one that runs those APIs. Even if you run them yourself, you still have a much smaller surface area around those APIs that are way easier to reason about. That does a lot for security but it also does a lot for performance because the more you prebuild upfront, the more you can take and distribute directly on a content delivery network. You can serve those files directly from the place where you visit yours at.
That also again for reliability just makes it way easier to scale. The more you can just push out to a content delivery network, the less you’ll have to ever worry about scaling for traffic spikes and the like.
I can mention a quick story around this, on Netlify was a company called Sphero that built the toy version of the BB-8 Droid from the new Star Wars Movies. It’s a pretty nice thing if you ever want to start a company, just make sure you get your toy into the largest movie franchise in the world and then start selling it. They somehow managed to do that but then up to the premiere of the new Star Wars Movies, they had to prepare for the worldwide launch of that and the traffic that would come with it.
They did that by essentially building out their whole site with the build tools which splits out all the cold pages. They were using Angular to do all the dynamics stuff at client-side. All the basics would already be pre-built and loaded upfront. They just put it on Netlify a week before the premiere of the new Star Wars Movies. I think we serve more than six terabytes of traffic for them in a pretty short time span.
Aimee: I want to backup and ask maybe a more basic question. Excuse me if this is a little bit of an ignorant question. On these slides, and you also said earlier hyperdynamic, that seems a little bit buzz wordy to me. Can you explain exactly what you mean by that?
Matt: Yeah. Basically when I say hyperdynamic I mean what do we think about of dynamic. There’s two things. One is that the content of the site refreshes, that it’s not just a static landing page that’s sitting around and not doing anything. Things like having a news publication or magazine where the content is alive. There’s just also all the parts of interaction, stuff like being able to do search on the side or comments, or filtering, or all these functionalities that we think about as dynamic.
That’s what I mean with hyperdynamic that we’ve gone from these sites that were dynamic by running a program on the server every time we visited to going to sites that are even more dynamic by running a program in your browser every time it was visited.
Aimee: Okay, that really helps. Because you know, I’ve heard static, I’ve heard dynamic, it’s pretty clear the difference but hyperdynamics wasn’t 100% clear. That’s more clear now. Thank you.
Charles: My question is how far can you take this? This seems like for a blog or something like that where the data structure isn’t that complicated, you probably have a few data types like authors, posts, and maybe comments. How far can you take this? Could you build a full on CRM on something like this? Or could you go into building out some complicated financial or medical software with this?
An example would be our own web UI. That’s like the web UI for Netlify that handles deploying websites and configuring as a sale, or setting up DNS or anything of that. All of that is a single page app in React that lives on Netlify and just talks to Netlify’s public rest API.
That approach on the one end is something that’s very much just becoming the way of building web applications more and more. There’s the other end which is latch content driven sites. There, I probably wouldn’t try to build something where the content, where you have maybe hundreds of thousands of pieces of content and they update fairly often.
These are definitely the kind of projects that shows that we have maybe when the only things people would built with these kind of tools where their own developer blog. While today we’re starting to see really interesting, really large projects getting built with this approach.
The interesting thing is that the larger the project, typically the more important these characteristics of performance, and security, and reliability becomes. That’s why even though this in some cases means pushing the limits a bit and figuring out how to do this with the JAMStack approach, that’s why we’re seeing agencies and companies going through that to get the advantage of side step. Pretty much response instantly and always stay up.
Brian: To go to Chuck’s point, it seems like this is building these static only sites that talk to APIs that you don’t control or build is still I feel like the apps that I use are useful because of data that lives in essential server. Controlling that data, controlling that API is really important. If you can farm 100% of your backend off to third parties, I feel like that really limits a lot of the interesting things you can do as a developer. You can certainly skip a lot of busy work. If you’re building an app that doesn’t really need a backend, that just showing web pages, that’s fine too.
Matt: I agree with that. I think it’s important that we have more and more open API ecosystem where we can use existing APIs. I think most people doing this will also build some of the APIs themselves. Not all of them but typically as you say you will have data that is really important to you. That’s part of the reason why your app exists. That data will probably also write at one to expose through an API than just threw some pick monolithic web app because you will probably also want to use that data from your mobile apps or for other uses.
I think you’re spot on in terms of it’s also an important part of it to have that you can do everything just with off the shelf API. I think one thing we are interested in seeing is also beginning to create a bit of an ecosystem for open source APIs where some of those might also be run as management services but where you also have the option of fronting them yourself or at that thing yourself for tailoring to your own use case.
Jamison: Another point to add to. netlify.com is actually a JAMStack site itself?
Brian: The whole backend API, it’s not a third party API. It’s API that we built. It actually has a Rails API that’s just rendering Json. The actual React app for consuming that Json. Presenting the data and we have through HTP we’re able to actually, I’m not sure what that means. We consume the API, we do that through that in the Redux. We handle with just as any other React app that would be handled isomorphically or universally, whatever the popular term is.
Another example, when I first moved to the Bay Area I had this issue where I ride the BART to the train system. I built this app because the very first week I started my job in San Francisco, there was the Bay Series, the baseball game. The baseball games between Oakland and San Francisco basically clogs up all public transportation. My idea was to build an app to tell me when not to ride the BART, or when not to ride public transportation, or when do I get home earlier.
I built that to a Rails API read as Json. I originally built it to some Amber app. Where I was just running that Json to Amber. Up and I say using the JAMStack approach we have the separate repo, you have your API which is what I built. I built it by scraping ESPN data. I was able to switch that to React app, I was enable to switch that frontend also to React Native app. I think that’s as far as I went.
I’m about to now look into doing it as a purely static site that presents the data, gives me notifications when not to ride the BART.
Just to go back to your question Jamison that the API itself, yes, it’s something I built. I guess only using off the shelf party API is more the ideal way but when you want to be your third party API, be able to do that as well.
Matt: Yeah, I think that’s a pretty good explanation. Also just to keep in mind that this is basically to create some nomenclature around and architecture for building sites. APIs are mainly plural because you often end up with the Stack talking to a bunch of different APIs. Some of them are your own, some of them come from other places.
Even in the Netlify app, we both from the web app, we talk in large of course to our own rest API but we also talk a lot to GitHub’s API, to GitLab’s API, to Bitbucket’s API. Whenever you configure project through any of those and so on. It’s sort of something that’s just snuck in and all of us. That was definitively just not something you could actually do in the browser a few years ago. It’s come together with pros origin request to come together with the death of i6 and 8. It’s really interesting how it’s becoming the natural way for working for a lot of developers.
Jamison: Yeah, it makes sense.
Brian: Serverless is a framework that talks to Lambda. I want to recommend start with this but I just want to bring up the point that you can actually have Lambda functions as your backend. This could get pretty complicated but there are some people who have done it. I know Kevin Old to seize on the React Native he host that podcast with Nader. He actually had a whole talk on this at the, I think that React Rally I think, maybe, last week.
Charles: Just to clarify when you say Lambda function you’re talking about Amazon’s cloud service.
Sites that have just a Json API, this is a mail pool. You could also do stuff like that. To answer your question originally on the roundabout way to get to this is I think any sort of rest API that’s available to you like Twitter or Facebook you just want to play with and try it out. How I recommend that? I do a bit of mentoring to a coach school called Block. I have one of my students actually building, we have started with a Rails app that talked to the Twitter jam. He basically just rebuilt twitter using Rails. We switch over to using React on the frontend. As a learning exercise, he took out the Rails and then put Node as a backend, and then express API.
The opportunity is basically unless you could try. I would recommend anything that is serving Json currently for you.
Aimee: Is JAMStack open source or close source? Because I’m trying to find it on GitHub and I haven’t been able to find it.
Matt: The website itself should be open.
Jamison: To be clear it’s not a framework, it’s not code, it is giving a name to this existing idea of building your frontend to consume third party APIs basically.
Charles: If people want to check Netlify or see other examples of JAMStack in action or their other resources, where should they go? What should they do in order to figure out what you guys are talking about?
Brian: Check out netlify.com. We do have a blog that we actively contribute to, at least more two to three times a week. There’s also JAMStack Radio which is the podcast that I started very recently, which we go to some of these details. We also talk not only to people who are doing JAMStack but also skeptics. We have some people from Airbnb on one episode that’s not out yet. I think from there you should be pretty good, good to go. We’re pretty active in Gitter as well. If you’re a Gitter person, check this out, Netlify.
Matt: If you’re in the Bay Area, we also run a meetup that used to be called SF Static Web Tech and now it’s called the SF JAMStack Meetup.
Charles: Very good.
Brian: Sorry, just want to add to just be clear. Netlify is not the only place we can host about JAMStack as websites, there’s surge, Firebase hosting also can do it, and those couple other ones too out there that I highly recommend checking out as well and comparing.
Charles: Alright. Let’s go and do some picks. Jamison, do you have some picks for us?
Jamison: I sure do. I’ll just start talking and then I’ll figure out how many picks I do when I stop talking. The first pick is called the Early History of Smalltalk. It’s a write up by Allan Kay on the origins of small talk. It’s an awesome look into some history of computing things that are pretty cool. There’s been a lot of work before all of us started programming. A lot of people had a lot of great ideas. It’s fun to see some of those ideas that have existed long before they became popular and even some that’s haven’t quite count on yet.
My next pick is, I think Brian already mentioned it, but React Rally 2016 videos are out now. They’re up on YouTube. You can watch things like Kevin Old’s Serverless talk. There’s also 19 other talks. As an organizer, I basically got to see two minutes of every talk so I’m excited to go through and watch them all now to see what the conference I organized was like.
My last pick is going to be self-serving. I run a software consulting company called Fivestack. If you got to fivestack.computer, you can see all five lines of HTML that I’ve written for a website. We build great software products. We’re looking for a couple more clients. If you’re interested in that, just talk to me through the email address that’s on that website. Those are my picks.
Charles: Alright. Aimee, what are your picks?
Aimee: Okay. This is a pretty good blog post. It’s a little bit older but somehow I stumbled upon it. I thought it was really, really good. It’s called Falsehoods Programmers Believe. There’s the main blog post but then if you click on the links, there’s one falsehoods programmers believe about time zones. They’ll give you a couple but if you click on the main header, they’ll link you to another article. It’s just a ton of stuff. Especially, we work in the community where I think it’s good that a lot of conversation about questioning, things that you take for granted.
One of the falsehoods programmers believe about names, about time, things like that. Especially if you are a frontend developer I feel like, I guess it goes too for backend but especially for frontend, you’re working on and accepting user input and things like that. There’s a lot of things that you might take for granted just based on your past experiences that you’re not considering for other people. I’ll put a link for this article in the show notes because I thought it was pretty good.
Charles: Alright. I’ve got a couple of picks here. Last week was crazy for me. If you are following the Twitter verse and you know what I’m talking about. If not then, not so much but it was that and the fact that I had to drive my dad to the hospital a couple of times. I had Angular Remote Conf. Anyway, it was just an insane week. I was super exhausted, frustrated, and a little bit angry. Anyway, my escape is a mixture of audiobooks and podcasts.
Anyway, I don’t know why but it just turned out that I was a couple weeks behind on the 48 Days podcast by Dan Miller, who actually lives in Nashville. It was exactly what I needed to hear, it was funny. I’m going to pick the show just because it was just one of those things where for whatever reason he was talking about some of the things that I need to know.
My other escape lately has been the Fall of Hades by Richard Paul Evans. It is the sixth I think book in the Michael Vey Series. I’ve really enjoyed the books. It’s nice because I can just sit and listen. They’re young adults so the plot structure and things like that aren’t as complicated as some other things that you find that are more adult genre fiction, or adult level fiction. Anyway, it’s really easy to listen to, really easy to follow. I can relax my brain a little bit while I listen to a fun story about kids who have powers, electricity powers.
Brian: So relatable.
Charles: I know, right. Those are my picks. Brian, what are your picks?
Brian: Alright. I’m actually a big fan of the podcast and actually listen to almost all of the Devchat podcasts. I know there’s sometimes some non so serious picks. I have my first not so serious pick is actually Jon Benjamin, I’m not sure if he’s a comedian but he hired a jazz band to play piano with him. It’s a band backing him on piano. He actually doesn’t know how to play piano so he plays with the Jazz band but then when it comes to his part it’s absolutely horrid. When he actually starts playing it’s a very bad piano. I recommend everybody watch that because it will definitely brighten up your day. Knowing that some guy is playing piano with a very amazing jazz band.
My other pick is RailsConf 2016. There was Stella Cotton, she spoke and she worked at Indiegogo. They got to a D-Bus attack. It was a giant monolithic Rails app. They didn’t know what to do so they have switching, I guess the resolution, I’ll give you the spoiler. They switched their actual entry point to the main indiegogo.com to a static site. For individual pages they also switched to static pages as well to prevent any sort of slashdotting. For example, I forgot which campaign actually did it for them but some campaign that basically blew up Indiegogo, because everybody was actually trying to view the site.
My other pick is React Native. Some people have been skeptics and have tried it a year ago. It’s come along a long way in only a short year. I recommend if you haven’t tried it, try it again.
Finally, my final pick is Kanye West. I am unapologetic for Kanye West. He came from nobody to producing beats from JZ. Now, he is kind of gone a little pass the line but there’s a podcast called Book of the A. I highly recommend listening to it. A bunch of guys who are big fans of Kanye West. They’ve been fans for a while and they talk about the good and bad about Kanye West. If you’re very interested into it, which I’m sure you are, check out the Book of the A podcast.
Charles: I just find the idea of podcast about celebrities fascinating.
Brian: This one is, you’ll be hooked. I promise.
Charles: Okay. Matt, what are your picks?
Matt: When I relax I like to relax by reading science fiction. Whether it’s sometimes really bad science fiction and sometimes really good science fiction. One really good author I’m enjoying a lot is Kim Stanley Robinson. His newest book is called Aurora. It’s really good. It’s a little depressing. It talks about this generation starship that’s been sent on an expedition to one of the nearest starts and has already been underway for hundreds of years. Generations of people growing up on the ship, about the generation that actually arrives to the star and what actually happens then and so on. It’s really fascinating.
His Mars Trilogy is pretty amazing as well. Talking about the colonization of Mars and expansion of human kind to the whole universe. I recommend that.
Charles: Alright, cool. Aimee asked a question I just want to put out there because I think it’s interesting. Do you have examples, you talked about a few but what are the other examples you wanted to give us?
Matt: I think the Indiegogo that just talked about sounds really, really interesting. Our own app of course is a typical example that’s a lot of those bounty sources has an open source app. That’s also pretty interesting.
This Sequoia Capital website is a really interesting example of a content driven site. Just because it’s like a lodge, a multiregional site with a ton of content talking to content full and eLogic job. Job API that the years to follow the job boards and everything.
sphero.com is a pretty fun example as well of. Often mean .com sites with ecommerce and so on that sounds pretty cool.
Aimee: Yeah. If you can add those to the show notes. I was really trying to look for some code examples because I felt like that would help explain things.
Charles: Alright. We’ll go ahead and wrap up with that. Hopefully folks will go check out those examples. We’ll catch everyone next week.
Brian: See you.