Wrapping Up

[00:00:00]
>> To just kind of take a moment here and recap what we've learned, the Jam stack is not a replacement for building things on the internet. You're building all the same things that you built before the difference is in where the responsibility lies. So we are still gonna build front end apps, what's different is that we don't also have to build the servers where these apps are uploaded.

[00:00:26]
We don't also have to handle the heavy setup of engine x or reverse proxies or setting up HD access, or Apache, or whatever was that you were using for managing domains. We don't also have to set up a CDN and making sure that things are scaled and the cache is invalidated.

[00:00:47]
We don't also have to set up our database. We don't also have to worry about scaling, our various servers horizontally and making sure that our databases are consistent across all regions at all times. We get to just offload that responsibility to someone else. And that means that we're able to very quickly with little additional help, with little blockers, take something out of our heads, get it into our editor and up onto the internet so that we can share it with the world.

[00:01:18]
We can show somebody what we're thinking, we can put little proofs of concept together very quickly, that actually function. And if you've ever tried to get buy-in for an idea at work, the easiest way to win is to build something that works. Because once people can click around something, they just start thinking yeah, this is great, what if it did this instead?

[00:01:37]
As opposed to, I don't know if we have time for that, right? So being able to rapidly prototype like this to show somebody how something works as opposed to having to try to explain it, or drawn on a whiteboard. That's not feasible if you have to do months of work to get something up on the internet.

[00:01:53]
But if you can throw it together in an afternoon, I mean what we built four apps in one day today. So we can prototype this stuff together very, very quickly to show what we're thinking, to show our work and let people see what could be possible. And that I think unlocks a huge number of doors.

[00:02:10]
So I'm really, really glad that everybody came today. I'm really thankful that you all showed up and that you're excited to learn. I'm really excited to see what you create. So does anybody have any questions?
>> Does vendor locking happen, does that code proprietary and precious enough that if for whatever reason you had to go from one to another, it becomes locked in?

[00:02:34]
>> I mean, it is gonna kind of vary between what we're talking about. So for the Mail app, not at all. That was worth 15 lines of code. So the amount of effort to shift that to another vendor would be relatively minimal. The pain would actually be more in setting up the domains and migrating the list and all the things that are kind of the administrative tasks around managing email.

[00:03:03]
For something like a database, it sorta depends, right? How does your vendor support exporting data? How does your new vendor support importing data? Do they both support GraphQL, and can you customize what those queries look like? Because if so, you could change vendors, and your frontend code might not change at all.

[00:03:23]
If you can't, then it depends on the scope of your app. Are you gonna have to go rewrite every single component, to change a little bit of the query? I don't know, then, yeah, sure, maybe that's locked in. But I think, the thing that's nice about this is that because all of these pieces are kind of separated, our frontend app isn't actually aware that our back end is using fauna or graphQL.

[00:03:48]
Well, it's sending a little bit of data to the serverless functions and then they're making decisions about things. So if we needed to change our to-do app from fauna to something else, even if that something else wasn't graphQL, we could switch over to a Postgres database. If we did that, the only thing that would change are those serverless functions.

[00:04:10]
And as long as their API stayed the same, they still accept a to-do and they still send back that response, then our front end code doesn't have to change at all. And so while these managed services do run a risk for vendor locking, If you architect stuff in such a way that you've got separation and concerns like that, where the database logic that vendor specific happens in one place, then your surface area for vendor locking becomes much smaller.

[00:04:40]
And that can free you up from a lot of hassle and overhead. I'm on Twitter a lot, probably more than I should be, but feel free to send me the things that you're working on, send me follow up questions. Hit me up with your proofs of concept and the things you're building.

[00:04:56]
I'd love to give you feedback, to see what you're building, and to kind of watch you dive in to this jamstack world. So thank you very much. [APPLAUSE]