Library Podcasts

Ep. #68, Edge Handlers with Matt Biilmann of Netlify

Guests: Matt Biilmann

In episode 68 of JAMstack Radio, Brian speaks with Matt Biilmann of Netlify. They discuss the plugin ecosystem, the state of the JAMstack, and what’s new at Netlify.


About the Guests

Matt Biilmann is the Co-founder and CEO of Netlify, the all-in-one platform for automating modern web projects. Previous to Netlify, he founded BitBalloon and Webpop.

Show Notes

Transcript

00:00:00
00:00:00

Brian Douglas: Welcome to another installment of JAMstack Radio.

On the line we've got the one and only, Matt Biilmann. Hey, Matt.

Matt Biilmann: Hey, it's great to be back again after a couple of years.

Brian: Yeah, it's been quite a few years. A lot's changed.

Listeners, when we say "A couple of years," Matt was on the podcast, episode two.

We talked about the inception of the JAMstack and where it's come from, and how it got started, and the adoption of the JAMstack at Netlify too, as well.

There's so much history, and it's funny because we just had Ohad on the latest episode that just released today.

Matt: Nice.

Brian: It was fun to get his story, because I've chatted with Ohad a lot but I never got the pieces of his story and how he got involved in the JAMstack and started Stackbit.

It was nice to get the whole story then. So folks, you can check that out.

But Matt, I don't know if people know who you are.

I'm sure they do, but do you want to introduce yourself and what you do at Netlify?

Matt: Yes, sure. I'm Matt Biilmann and I'm the CEO and co-founder of Netlify.

Netlify of course, we took an early bid on the JAMstack and built a platform for developers to build and deploy modern websites and applications that follow these JAMstack architectural principles.

Brian: Excellent. Again, I can't reiterate, you were literally on the podcast with me and we talked about that history.

So we can leave that for the listener to go listen to that, if you weren't around for all those episodes, but I want to talk about Netlify today.

We just finished JAMstack Conf just last week, so if you want to know the date of when we're recording this.

There are quite a few things that shipped just in a conference, and I love the lightning talks. When it's like, what is it called?

Matt: Lightning Launches.

Brian: "Lightning Launches,"yes. I saw Chris and his toast dev and a couple other things, but Netlify launched something.

Do you want to talk about what y'all shipped?

Matt: Absolutely.

One of our big releases at the conference was a new feature we call "Edge handlers" that we've been working on for quite a while, and that we started opening up the early access of now.

Then originally when we started, we build out our edge network and we had this declarative rules engine.

So you could pre-build any HTML, CSS, JavaScript and push it directly to the edge, and then you could redirect the rewrite rules that would be able to do quite a few things with.

Like, rewrites or GOIP based rewrite, language based rewrite, even authentication based rewrite, but it's still just a declarative ruleset.

Then back in 2017 or so, we introduced Netlify functions that really added this concept of a compute layer.

Where you could run code on Netlify dynamically, but really targeted towards the idea of you get the initial HTML from the edge node directly and then you can start doing API calls to functions and use the micro services and so on.

But architecturally, we could still see that there was some use cases where you couldn't quite get all the way there just with a declarative ruleset at the edge. You needed to do something during the request response cycle, for example, more fine-grained authentication patterns than just deciding "This user should have this role or another role."

Things like, instead of just saying "If the user is in this country show this,"maybe saying "We are a large retailer. If the end user opens up the site from a location that's really close to one of our stores, then show that store directly, and otherwise show a generic page."

That's more logic than you can fit into just a declarative rule, so edge handlers really take that whole edge routing, response, transformation layer, all of that, and makes it completely programmable in JavaScript so you can just write whatever logic you want there.

And that's, of course, something I'm really excited about also. It's a new building block for the JAMstack.

Brian: That's fascinating too, as well.

I'm a Netlify functions user and I have a Stripe store to sell stickers hosted by Netlify and powered by Next, and all the bells and whistles.

I think that's fascinating too, as well. Because I remember your co-founder, Chris, also my former boss, I remember chatting about one of the things that he was super excited about when he was in Denmark for an agency.

I think it came up around Pokemon: Go. Having the ability to know when people are at certain places and using AR to actually identify "There's a group of people here who are trying to catch this Pokemon, Let's all collaborate."

It might be a stretch, but maybe this is where the JAMstack is going, where there are limitations to functions and there are limitations to only hosting on the jam.

I think you're creeping to the edge, I guess, is the term I'll use and the phrase.

Matt: I'm pretty excited, too. Every time you build a primitive like this that developers can use, one of the most fascinating thing as someone who builds a platform is to see all the original things that people come up with and start building with it.

So, I'm really curious to see that. I think there's a lot of use cases that are quite Enterprise-y.

Again, I mentioned big retailers doing globalization and companies doing personalization, fine-grained A/B testing, maybe using it for edging clues for really big sites, and so on.

But I think there's also a ton of opportunity just for developers to poke around and come up with new patterns and new ideas, for example, let's say you you're building a site generator and you want to try to build device specific bundles, for example.

So you serve different bundles based on browser capabilities, or something like that.

You wouldn't really be able to necessarily deliver on with just the current rules engine, but you could totally just write an agenda that would say, "If this user can serve this bundle otherwise this other bundle, like this."

There's all these creative things that people can start experimenting with that I'm really looking forward to.

Brian: It's really intriguing too, as well, because I know this is a little more of a naive example too, as well, but I know things like when you launch on Product Hunt and it usually as a ref code, and with that ref code you can treat the site differently based on that.

Matt: Certainly, for example.

Brian: But also just being able to infer and not actually have to manipulate the actual URL to change what's happening, actually infer what should happen is mind blowing, to be quite honest.

It's stuff that I would think I would need a server, I'd have to go reach for a node server to constantly check and make sure this is working.

But what you're saying is that you're able to actually compute this on the edge and do that logic?

Matt: That was a great example, that one would be fun to implement.

Things like reacting to the referrer, so that's totally possible and it should be really easy to work with this model.

Brian: You need to activate your developer experience, folks, when you move to beta and launch on Product Hunt again.

Matt: I'll totally bring up the tip, I hope you haven't patented it already.

Brian: Oh no, it sounds like I'm consulting now. I'll look for the check in the mail. Honestly, what Netlify has unearthed, it's a movement.

The JAMstack is a movement that not just Netlify is driving towards, but you see so many other companies also taking part.

I'm super impressed with all the plugin ecosystem as well, so Fauna being one and Algolia was just announced too, as well, recently.

Matt: Snyk as well, Nimbella is another interesting one.

They basically launched the whole new Serverless runtime for Netlify basically, as a plugin. That's really cool.

Brian: You mentioned the term "Primitive," which I think is really apt for the idea of what this is, because Netlify--

If you watch the feature, the edge handlers have an idea of "Go ahead and run with it, developers."

I'm sure your enterprise customers are also bending it to its will.

Matt: Of course.

Brian: But individuals are able to take those primitives and wrap their own ecosystem around it, which is mind boggling that at Netlify your ecosystem, your platform, you have these primitives that people can now add their hooks into and build their own ecosystems on top of.

So, now it's going to be-- I don't know if this is too forward thinking, but is it possible that Netlify could be another--

Not a flavor of AWS, but perhaps building its own infrastructure for people to adopt these patterns without the need of getting lost in the console?

Matt: To some degree.

We really are building out, you could call it, a Serverless cloud that is also not in the same way tied to one provider, so we are not building our own search solution or our own data based solution and so on.

But we are starting to really make it extremely easy to combine and work with all these different providers and premises.

The FaunaDB add on is a great example, the Algolia add on is a great example.

Of course, what sets us apart is being still quite opinionated around the architecture.

That's what makes it possible for us to make it so much simpler to work with and so much easier to set up.

You can only do that if you have some architectural opinion, otherwise it's a question of "At what level do the premises you give people lie on?"

Of course, for AWS it's very low level infrastructure, primitive.

They are very powerful, but since you can do everything with them, just figuring out how to put them together for common purposes can be a lot of work and maintaining that can be a lot of work.

So, when we didn't come with a more opinionated idea around "What should your stack look like?"

Then we can take a lot of the friction of doing all of that work and just remove it, so developers can just work in their git repository and their infrastructure just flows from there.

Brian: Honestly, the opinions that Netlify is shipping on the backs of these features, I love.

I've been doing a lot of live streaming, which listeners, you're very familiar that I've been live streaming on Twitch.

But I was able to launch a new design system by using a subdomain on a URL I already own that was managed by Netlify's domain management system, and the effort that I did to make all that work, it was an afterthought.

I was like, "This should be on a subdomain. Let me go to fill it in the form, it works."

Within 30 seconds I'm now moving on to the next problem, and I'm not trying to figure out things like DNS and waiting for things to propagate, it's just magically working.

I could see this edge handler, this compute layer of me being able to find out and take advantage of these primitives.

I haven't had a chance to actually dig in as of yet, but the concept I'm familiar with and I'm excited to actually start doing some of these that are unique situations, because I think you're at home and I'm at home and we're having this conversation through Zoom.

To be able to have a unique experience where now I'm actually chatting with people in India on a regular basis through the content I'm doing, if I wanted to provide a unique experience-- I'd mention, I have a store powered by Stripe.

I like being able to just understand if someone from India has logged in, provide them with their own price, their own stickers, their own whatever, based on what I can ship there.

Now I can do that on the computer.

Matt: That's really cool. That's cool, I'll make sure you get early access.

Brian: I think I clicked the button, I might be on a list somewhere.

I have to follow up through emails. As a former employee, I'm still pretty die on that Netlify and trying to make sure that all my stuff runs there and being able to showcase the features that exist.

I love the fact that I don't have to be a DevOps engineer in addition to my front end UI skill set.

I don't have to manage servers, and that's what I want.

Matt: The other thing we announced at the conference, SNU primitive as well, that's coming really soon to all users, at least on the pro tier and up. It's background functions.

Brian: Nice.

Matt: So that's another compute layer, where Netlify functions is always meant to run during a request response cycle, so they're great for micro services and API endpoints and so on.

But sometimes you just want to start a process, if someone buys something for your Stripe shop, maybe you want to tell them immediately "I've gotten your order."

But then you want to run a process that maybe connects through some API to tell some service, to sell stickers and send mail to you telling that someone bought it and all of these things.

That you would rather just have happened in an asynchronous function that can run a drone, so we launching background functions for that.

I think we came to a pretty elegant solution by just having any function you have, if you just append to the name of it "-background,"then it will run in the background when you trigger it instead of running in the foreground.

So, they are really simple to write.

Brian: That's a new feature for functions today? Like, it's available?

Matt: It's coming at the end of the month.

Brian: End of month? OK, I'll be looking forward to that.

Because I've been stretching functions a bit and trying to see where the ceiling lives, as I mentioned I like the architecture.

I like JAMstack, I like writing UI and I don't writing a lot of server based stuff because I just want to operate in the space that I am comfortable in, and that's where I'm comfortable.

With Netlify I get opinions of how to get things done and how to ship it quickly, so that's exciting.

I'm looking forward to that, and I actually missed that announcement during the conference.

Matt: I'm pretty excited about those as well.

I think it's time to give us a really complete set of primitives with edge handlers for anything that you can do in a few milliseconds directly at the edge.

Routing, transformations, anything like that.

Then functions for anything you can do within a second or two in an API response, and then background functions for any longer-running compute tasks.

Again, I'm also excited to see what people start building with them.

Brian: Me too, I'm excited to start building.

We covered the edge handlers, we covered the opinions in these primitives, and I think these opinions are strong enough that we recently just announced within the last actually four weeks-- I think it was earlier at the beginning of the month.

Netlify crossed a million developers on the platform, which is-- Congratulations.

Matt: Thanks.

Brian: In the previous podcast I said "Congratulations to Netlify" when it happened , but now I'm saying directly to your face and saying "Congratulations."

Matt: Thanks. You remember when we were six people back in Dogpatch and starting to build all of this, so it's been amazing to see the whole community formed around the JAMstack.

Of course, seeing that part-- Of course, there's many other platforms and many other players in the space now and the whole category is maturing and growing up.

But seeing that amount of developers coming onto our platform, and by now of course we test right through that million mark and have been really-- Just keep seeing that level of growth and reaching that many developers is pretty incredible.

Brian: It is, and I remember-- It's funny because I remember having the conversation of us just deciding to even adopt the term "JAMstack" and the way that we explain Netlify.

That you are using JAMstack to be able to ship sites, and if it's yes you can use Netlify.

Having that conversation I would have never thought we'd be here for four and a half years later.

Now we have a million developers using Netlify today, which also seemed like a pie in the sky number.

As you saw-- Understand the timing for the listeners, this was at the time where Firebase was just now deploying the Google version of Firebase, and they had the Firebase Deploy and then we saw Parse basically shut down.

We saw all these other tools shutting down and pivoting or getting acquired, so we didn't know what would happen with the space and how it was going to grow.

Matt: Obviously a few of us were crazy enough to have a pretty strong belief, and our hope from the beginning was very much that we had nailed the right part of what sent a fundamental architectural change that's going to happen, and "W hat is it that we can build something really long and lasting on top of?"

Versus, "What's the part of the stack that keeps changing very fast and keep iterating very fast?"

If you think back to when we started, Angular was the biggest thing when we started out and it seemed unbeatable, and suddenly React came along and became everything.

There's so many different frameworks and flavors of the day that's been coming and going, and in all of that time it's been such a space of rapid innovation.

But I think we identified pretty correctly that this tendency to really make the front end and the front end web layer its own thing decoupled from the back end, and this tendency of the back end layer to start splitting up into different APIs and services.

Where some are your own services, but a lot of them are other people's services.

Like Stripe, Algolia and so on. I think that observation has really helped through till now, and of course that's been what's powering this idea of a JAMstack architecture.

It's also really the framework that we've built Netlify around.

Saying "If this is happening, what are again the platform elements, the primitives and the workflows we can give developers to be really successful in building with that paradigm?"

Brian: It's proven to really stand the test of time.

As you mentioned, frameworks are coming and going, and flavors of JavaScript.

Recently we saw Moment.js move into maintenance mode and now people are now choosing new versions of how to handle date/time.

So maybe it's too harsh to say it's a fickle ecosystem, the JavaScript ecosystem and the front end ecosystem, but I think that's really what it is.

It's true. Now we have Rust runtimes that are faster in compute time.

Matt: Yeah, really interesting.

Brian: I shipped some Rust thanks to Thao, I think he had a blog post--

Matt: Nice.

Brian: And shipped a Rust powered Netlify function to power my front end JavaScript code--

Matt: Nice.

Brian: I was hanging out in the Party Corgi Chat and he posted it, and I'm like, "I'm going to run through this."

And then in ten minutes I had a Rust powered front end hosted on Netlify, which was amazing.

Matt: Nice, that's awesome. I also just wrote my first bits of Rust, and it's a really cool language.

Our whole edge layer now, we rewrote the core edge layer of Netlify in Rust in part to really build the capabilities we would need to offer edge handlers.

That's been a really interesting process.

Brian: Talk about a language that stood the test of time, and as people were--

Because I know even five years ago when Rust was just entering in the scene and people figuring out with Mozilla putting a lot of effort behind it.

Now you're seeing Rust really getting adopted, even on the web and the browser with web assembly.

Honestly, I'm not surprised to hear that you wrote stuff in Rust because it seems to be where Go was the language for the cloud, Rust is now being adopted in the CDN programming, edge layer programming, i f you want to get that speed.

Matt: It's a really interesting language. I mean, we still use a ton of Go in our infrastructure, but for us Rust really looks like the ideal replacement for anything we used to do in C++.

Brian: For sure. So I wanted to transition to a couple of different things, at the JAMstack Conf you had a conversation with Matt Mullenweg-- I believe I pronounced his last name correctly.

He was a co-founder of WordPress, and it was a great to hear the conversation to hear his side.

I spent the last episode actually chatting with Ohad about his response to the blog post and understanding where Matt was coming from in saying that JAMstack had some issues.

We talked through those issues in the last episode, but I'd love to actually talk to you about that too, as well, and that conversation.

Basically, the state of the JAMstack moving forward.

We now have opportunity with Netlify to host edge compute layers and be able to write that code and make sure that works.

Matt: And of course, again we're freely remembering that the JAMstack, of course, encompasses much more than Netlify.

We've seen just incredible growth in the last five years and keep seeing that, but the whole ecosystem has grown enormously.

Today there's several different providers in the JAMstack space and all the big cloud providers have JAMstack offerings, and I don't see any sign of that possibly slowing down.

Again, I'm very convinced of this tendency for the web front end layer to be its own thing happening.

That's, of course, a point of contention with Matt Mullenweg, because in itself we have lots of clients using WordPress successfully with Netlify with a JAMstack approach. It's become a quite popular headless back end for JAMstack projects.

Live chat had a great case study out around how have they rebuilt their whole front end with a JAMstack approach, but still using WordPress as a headless layer.

We see a ton of those use cases, but of course I would say that for Automatitc as a WordPress company, having what Matt referred to as "The integrated approach."

Where all the templates and plugins and everything live together in one monolithic system, it's probably quite essential to the way they have built a business model.

Of course, that's probably where some of the disagreement comes around.

Of course, once you start really completely decoupling the front end presentation you also open up for a whole new ecosystem forming with all these different APIs, services providers, new open source tools and so on.

I'm very positive towards that and probably Automattic sees it in a different way.

Brian: Honestly, I think with Automattic, what WordPress specifically being--

Powering such a large amount of the web, I think there's opportunity for them to get very comfortable in what that means, in being part of the web.

But I think in the conversation, what I got as a listener of the conversation is that you both were making really good points but I don't know if you were having the same conversation.

Where Matt was really-- Was focused on the space that they own and are really dominating in, and your conversation was actually about the space that's being created.

I look at it like, I know the joke has been said about your developer experience engineer Cassidy being the TikTok developer advocate.

Which is like, she's amazing on Twitter and her videos are top notch, I am engaged in every single one of them.

I know exactly what tweets she's sending from the Netlify accounts too, as well.

Her humor is right on point and it's welcoming, and the fact that she's also on TikTok and she's doing developer engaged content, is something that if you're doing developer experience or you're in developer relations--

I have a point what I'm getting to, but what I'm saying is that TikTok is something that you probably want to pay attention to.

As far as content goes, because now people are paying attention to it.

But I think the same way where TikTok is something that I could be like, "No. Facebook or Twitter is where I need to be."

I think it's the same thing with WordPress, where I feel WordPress could say or Automattic could say "This is the place where everything's happening. This is where I put the future."

And then one day TikTok comes and upsets them. I think it's the same thing with the JAMstack, whether it's Netlify or whether it's Vercel, whether it's Gatsby.

Whatever the tool is, there's so many other players that are now growing adoption. It's very exciting to see that.

Matt: I think there's always, with any of these things there's always a group of people you should pay attention to with social media.

It's probably good to look at really young people and see where are they starting to end up, because it tends to be a pretty good indicator that that thing in the future will be really interesting.

With technology, I think it's very often about looking at the developers.

I remember back when I bought my first MacBook ages ago, after having had Windows computers for quite a while and I played around with Linux and so on.

But I bought this MacBook and it suddenly came with a Linux terminal, essentially.

But together with this beautiful operating system and so on, I got really excited, and then as I started to go to developer conferences I suddenly started just seeing more and more developers with these Macbooks.

Even if, at that time, it was still Windows machines which was completely dominating and Apple was a very little thing. But I think once the developers really started getting on board and getting interested in it, then they started building all these things for Mac and suddenly it became a really vibrant and really interesting ecosystem. That's what I think we're seeing some of the same with the JAMstack right now.

We're seeing that, of course, right now it's appealing more to a developer audience.

The adoption of it is quite driven by developers, but I also think that's a sign that once developers really start adopting something then they start building on top of it and they start being creative around it.

That's what I think we'll see happening around the JAMstack, and that's why I'm still-- Of course, very bullish on this ball keeping on rolling and getting bigger.

Brian: Honestly, well said. Seeing that adoption in Mac in the last decade or the decade before last. But what is time these days?

Matt: Who knows.

Brian: But you bring up Mac, And I think of the-- And pure speculation, but I remember when I was in college Steve Jobs saying "We're never going to make a phone."

And then literally six months later, they're like, "Here's a phone."

Pure speculation, so feel free not to comment, but I wonder if Automattic releases their JAMstack approach because we already have the WordPress API.

So like, if I just want to stand up a front end that's powered by stuff that connects to WordPress pretty easily, and I get my CMS, it would be a good play for them, to be quite honest.

Matt: It would be awesome for the ecosystem.

We've seen some of the other more traditional monolithic CMS, especially Ghost took a really radical React architecture and said, "We are going to really split up the front end layer and the back end layer and craft CMS going up in that direction."

It's really taking the headless story serious, so I think there's plenty of room for these existing providers to do that.

Brian: And it's a testament to the architecture too, as well. Being able to-- I saw this with Forestry and TinaCMS where they have their experiments-- It's not an experiment anymore, but it's a legitimate solution at this point.

But they're able to test us out and be like, "We have this other thing that is not closed source, but it's a system that you have to be all in. But we have this other thing which is open source and it's headless, we're going to try this and see if this is going to work."

Matt: That's true. Also another example of once you get developers excited, they start building all these tools for marketers and for content editors, and so on, that I'm very excited about.

Because I think there's going to be a lot of innovation and advances made also for content editors and non-technical users, based on developers being able to focus in a more "I'll build a service just around the content editing experience."

So, just around the live viewing experience and having that focus, I think, in the end of the week each of the services is really interesting.

Brian: Excellent.

You mentioned that you're very bullish on the JAM, I'm bullish on the JAM. I'm all about the JAM here. Pump up the JAM, all of the above.

But with that being said, I want to put aside some time for jam picks as well, but was there any last words, anything else you want to mention about Netlify that folks to try out things coming down the road map?

Matt: Go sign up for early access for edge handlers, and stay tuned for an announcement with the background functions coming out at the end of the month.

Just to say, in general we have a lot of exciting things on the road map.

Brian: Excellent. Awesome. Shipping no matter what environment, I love it.

Looking forward to getting my hands on these features and trying them out and writing my content and talking about them.

So, with that being said, we're going to transition to jam picks.

These are the things that we're jamming on, it could be movie or food or tech related.

Nothing is out of bounds, but at this time in the world we are always trying to keep ourselves energized.

Which if you don't mind, I'll go first, Matt, and share my picks. My first pick is Snowpak, Snowpak is a bundler.

One of the last blog posts I wrote for Netlify was actually a comparison of different bundler tools, and I've never forgot all that research I did to make those bundlers work and test them out and see where the ceiling was for that.

What I love about Snowpak is they've taken what you like about web pack, but also what you like the ease of use with something Parcel, and they combined that.

So now you got a fully configurable functionality, and you just literally just install it, it is inferred, and you have an entire developer environment with Babble and all the other cross compilation and stuff that.

So, a big fan of Snowpak. I actually had Fred, who's one of the lead maintainers on that project on the podcast here, which was my introduction to Snowp ak. I'm a big fan of it.

Matt: I find it really interesting as well. I guess I would then pick Chris Biscardi's Toast that you also mentioned earlier, his new site generator.

It's like Rust tooling for a JavaScript site generator, and so on. I think that's really interesting.

Also, because when you talk about building lots of content and so on, I think the fact that JavaScript itself doesn't have any concurrency model that can take advantage of shared memory, you can only spin out individual processes with their own memory objects and so on.

But you can't really put a content model into memory, make it immutable, and then just run a ton of parallel processes with access to the same block of memory that will always hold back the limits for how fast can you build really vast content based sites with a static approach?

I think once you start moving into Rust land and so on, that becomes a completely different ball game.

I'm pretty fascinated to see those interesting mixtures where you can make parts of the plugin system or specific rules and so on programmable in JavaScript, but make the core engine based on a language that can give you a very different performance characteristics.

Brian: I'm a big fan, and I've been watching it from afar. I'm super happy that it's now in a usable state.

I chatted with Chris right before, he actually came on and talked about MDX on the podcast. I need to have him back on and we'll give a nice Toast talk.

Which, what a great name to talk about the jam.

Matt: Toast to toast.

Brian: Excellent. So, Matt.

Thanks for coming on and chatting, just giving me updates with Netlify, an update with all the things that you're shipping and the stuff that you will be shipping soon.

I'm sure our listeners are ready to start signing up for these alphas and the soon to be betas for the background functions, and thanks for your time.

Matt: Thanks for having me.

Brian: Listeners, keep spreading the jam.