Architecting Fullstack Solutions in a Jamstack World

architecting full stack solutions in a jam stack world lots of material to cover let's get right to it now one of the things i want to talk about before we get to too much further into it was just a quote from uh somebody named cassidy williams so she's a developer advocate at uh i believe netlify and she wrote this on twitter not too long ago and i thought it was really a really good explanation of jam stacks so she says jamstack's about building web applications in the same style as mobile applications the ui is compiled then the data is pulled in as needed i thought that was a really kind of concise sort of thought and we're going to keep that in mind as we move forward through today's presentation [Music] so i'm going to break down our development into two kinds two kinds of solutions we have apps we have apis apps could be you know static websites dynamic websites mobile apps smart tv apps pretty much anything with a user interface whereas apis well these are things that expose data or they perform actions on that data well they could be manipulating that data they're really sort of back-end type things and you know we could be calling another api so we could change chain these apis together and i believe it's an api driven world out there and more and more the the things that that we need to be able to do are available to us as back-end apis that we don't even have to they don't even need to have to have a user interface anymore these apis are available for almost everything that we need so full stack it means worrying about everything all at the same time we're worried about the front end the app the apps that we're writing and the apis that they're calling and all that sort of stuff and this is why we have to come up with good architectures for how these things are going to work together so what are those things that need to work together well that's the front end and the back end these things need to have some kind of harmony right front end for encode is going to be like javascript in the browser it could be css could be html anything with a visual design so people who consider themselves front end developers these are the kind of things you're going to be concerned about and design systems things like that back-end it's server code it's databases caching system architectures multi-tier systems so sometimes it's different kinds of people so some people identify hey i'm a front-end person i am a back-end person and some people identify with both right well what has happened in the past is a lot of apps have been built that i consider are monoliths and monoliths combine both the front end and the back end into one big app and this is the thing that happens and then what happens typically is they get bloated and huge and then you have to rewrite them right and it's really hard to kind of pull the pieces apart well lots of architectures now are saying well let's have the back end and the front and let's kind of keep them separate so that we can take them apart if we need to let's keep the api separate from the user interfaces and things like that one of the things as a you know someone who's looking at designing a full stack architecture is to understand where is my code running it could be running in a browser especially with javascript it could be running on a server javascript can run on a server too and it could be running as part of your build when the site is sort of building for the first time or as you know as code has changed a hint here check your console.log statements wherever they're going that's where your code is running so you know for the browser that's the the developer tools and things like chrome safari or edge browser whatever firefox on a server you know a lot of servers have server logs that you can check that where your console.logs are going to be output to and getting the logging mechanism right on a server is really important and a lot of build systems a lot of devops systems are going to have build logs where the console.log statements will go as well and this is one of the things about jam stack it kind of plays mind games with us right because we can have code that could run in a lot of different places it could be that the same code you write runs in multiple sort of environments we have these frameworks that we normally think of as front-end frameworks things like react or view svelte angular whatever that we normally think of hey there's the components that are going to run in the browser but then there's these hybrid frameworks and static site generators to do funky things like taking those that react code that we wrote we thought we wrote it for the browser and taking it and running it on a build server that generates static html among other things and then there's a concept of serverless functions which can also run javascript although they say they're serverless this javascript is indeed running on a server and you know we first thought of this with uh saw this with aws amplify with adios lambda functions i should say but the concept has really taken off so azure functions we've got this google you can write functions the same kind of way and then netlify versel and then actually even gatsby has announced that they'll be uh supporting uh functions on their new cloud hosting platform as well so it's really incredible to get started with all these different things where your code can run and what really cooks my noodle is the idea that a framework like next js and gatsby that functions built in right so you can kind of do a little bit like a monolith as well with those but it still does a really good job of separating those so sometimes you want it kind of monolithic as in so i can do everything in one project as in that hybrid framework um and then it also is important to understand how we can pull those apart if we need to as well let's dig into next gs just a little bit so it's as i said it's a hybrid framework with a static site generator it can also do server side rendering okay so it can run our code in a bunch of different ways client server and a build it has functions built into it so everything in the api folder is those are functions so serverless functions i should say it has preview mode so i can deploy one project with nexjs it has a static site generator it can have server rendering it can have functions as part of that same project this is kind of feeling monolithic we're not going to call it monolith we're going to call it a hybrid framework has that preview mode built in so it's really powerful it also has something called incremental static regeneration which is a mouthful but that that is used for say we have you know a site that has uh 10 000 ecommerce products right and say there's only about 100 of them that we need to have built as part of the build process well those you know the other 900 uh 9 000 of them or whatever we don't necessarily need to build all those at un unless they're needed to be built right so what we can do is have it incrementally regenerated statically so the call comes in a serverless function is going to run that pretends that it's a page to generate that while there's like a little loading message that happens in the browser so this framework is really smart about doing that and it's a great place to start if you're looking at a full stack solution it kind of does the things that a monolith used to do but in a very jam stacked way where it keeps the front end and the back end really clear i would say the other really popular framework that i find myself recommending a lot is gatsby so what is gatsby well it's also static site generator has preview mode it has incremental build and just recently announced there's the ability through gatsby to through gatsby cloud to do hosting and functions as well and so the you know the easiest place to get gatsby running is indeed on gatsby cloud you just point it to your github repo your any git repo basically and it does the build incremental it does preview mode for you and a bunch of other stuff including you can get set up hosting as well but you can also run this yourself you can roll your own gatsby build server and preview server however you want it's something like a docker container there's lots of stuff out there to help get this set up so don't think that you're getting locked in with anything but gatsby cloud's just a lot easier and i think it's a really good product if you're if you're looking at doing a gatsby site [Music] so let's follow the flow of our code as it works its way from that repo to the ui so when we check our code into source control or we like we merge a pull request and our code somehow lands in that main branch a build is triggered okay and that's going to execute sort of like npm run build or yarn build something like that well at that point the build code's gonna run it's gonna pull code from like they had the cms so something like agility could be running pulling products in from our e-commerce you know something like shopify or bigcommerce pull that in it's gonna call all of our build time apis so where that build process is running from is important because if it's going to call an api that's really slow or something you know if we could move that closer or make it faster that might be important all right but then somehow it's going to generate that static site okay it's going to put that out there so now we have those static html files which is kind of the whole point of jam stack right get a static site out there we don't need to have a runtime web server to run it now we've got as cassidy was saying we've got that browser kind of build that's out there we can think of that like an app now because that now that browser can do something it can actually call apis right it's very similar to our mobile app mobile app can also call our apis right so that's where these serverless functions come into play we can consider those as serverless api functions that we can invoke from the browser or from our app using http fetch or xhr calls okay so those are the ones if you're looking in your browser under the network tab for xhr for like google google chrome that's where those will show up right and lots of different we can consider them websites but they really act like an app in this case right so what's important here is that those serverless api functions aren't limited to the browser app so we can write the same code that gets invoked you know on that serverless function from the browser from a mobile app from a smart tv all of those things that have a user interface so these apis are really valuable we want to spend our time putting them in the right place and building them with the best back-end services right so what services are kind of available well you name it it's out there and they're evolving quickly things like authentication you know how do i log into my website that's something we would call from a serverless api you're not going to write a login function from the build server that doesn't make any sense it does make sense to do it at runtime in a serverless api we could we could call our database we could we could call it messaging so it could be that there's some event we want to send send out an email or send it an instant message so that that could happen there we could be doing data processing it's a really important pattern to take into account where it's like we want to put you know save some data do something and then have something that processes it a serverless api function can do that as well okay or there could just be other apis that we that we want to call there's and as i say there's lots of them so what are some you know examples of some brands that do this you have things like auth00 which is you know emerge that's one of the leaders for authentication fauna is a great product for databases twilio has sendgrid there's zapier for data processing cloudnary's out there is a pretty cool service that does all kinds of apis for digital asset management again this is just an example there are tons of best practices that are kind of evolving and sort of emerging players that are like the best in best of breed we call them that are being useful online to call from serverless functions let's take a deeper look at database specifically okay just to show you that there's a lot of different ways that these things can evolve okay so we took a let's look at a product like fauna and then compare it with azure sql server and amazon neptune okay so fauna i call it like a new school database it's a database as a service right it's globally distributed and it's kind of designed for serverless functions this is what it's meant for contrast that with azure sql server which is kind of old school sql server's been around for a long time it's a database server so it's kind of more of a server kind of a concept as opposed to serverless it is really an attack vector okay we hear the idea of sql injection about you know there's lots of ways to kind of get data into the database that it wasn't meant to be there or call commands that we weren't meant to be invoked that's a real attack vector it's designed for intranets it's designed to be behind a firewall so we don't want to call it necessarily from the same functions that we would be comfortable calling fauna with [Music] by the same token amazon neptune it's it's you know it is cloud scalable it's a very flexible solution but i also consider it an attack vector i think it was built along the same lines you know although it was designed for hyperscale it's super flexible i think we should be calling that from something within amazon if we can um based on how it was built okay we can call it outside of there but let's look at how we you know how we that best practice here so fauna great for calling for something like a versailles or netlify function where you know we don't have a lot of different resources in for selling notify we have our static site that gets built and we have functions that are in there and all the other services are kind of outside of there whereas with address azure and amazon we can write azure functions we can write aws lambda functions that are basically next to our those cloud resources okay they're close to it this is this is let's illustrate this difference in a different way so you know from fauna we can call it from netlife or cell gatsby cloud functions is a new thing you can call it from anywhere azure sql server we should be calling from an azure function that's an azure resource right lambda functions in aws can call our amazon neptune resources they're aws resources so we have an edge-to-edge kind of idea with fauna and a database as a service and we have the concept of resource affinity we want to be in the same sort of resource group for things like azure aws and google cloud could be the same thing now google has a firebase product which is again it's similar i would say that's more similar to fauna but you know specific regards to azure sql server so a lot of us as backend developers have written sort of sql code and it's really chatty and it needs behind the firewall well we can put an azure function in there that only only that azure function has access to that sql server on that same sort of intranet mini intranet and then that azure function is now on the edge we can call that from wherever we want right so there's just a couple different ways to think about this and sort of by drawing these boxes around them we can understand that if you have an azure sql server it should be called by azure function and that seems to make sense and that can be part of your overall architecture [Music] it's important to go ahead and draw those boxes and sort of line up the lines that connect these things let's look at a few of the architecture patterns for jam stack three three patterns in particular that i think are gonna help you visualize these things first we're gonna call static plus edge okay we're gonna take any static set generated site and combine it with versailles network functions and other apis then we're going to look at more of a hybrid plus edge where we have like a specifically a nexus project although this could be a casper project now we're going to call you know we're going to call it with versailles notify functions and again any other api in the world then we're looking at the static plus cloud kind of architecture where we have again any static set generator so the getting the static site built is like job one we're going to assume that you we can get that done but then how what do we do for our serverless functions in this case we're going to use azure aws functions and we're going to call internal cloud resources right and you can kind of mix and match these but these are just the example architectures so let's look at static plus edge so we have our static website it's going to use browser fetch to call a serverless function and then it's going to call use server fetch to call basically all the apis in the world right all the apis in the world that are meant to be called from a serverless function on the edge things like authentication database messaging data processing we talked about before you know ecommerce ugc search there's a you know some big ones that sort of come in a lot of conversations and it's like and any other api there are lots lots of different kind of categories do your research here but it's important to understand we are not calling these directly from the browser although in some cases we might need to but most cases they're going to kind of get me routed through a serverless function we're chaining together these apis so again any static website we're going to deploy the functions separately we're going to use serverless optimized apis right so these are things like fauna where it's a database as a service as opposed to calling into our you know our azure sql server that really shouldn't be calling from an edge service let's look at the hybrid plus edge uh and and this is interesting so now we have our static site that's been deployed but the serverless functions like in a next.js project are are built in they are part of the same project we call that a hybrid website i'm not going to call it a monolith although it kind of is acting like that but at any rate the browser is going to be again be using browser fetch to call those serverless functions and the service functions are going to use server side server to server call to fetch again all the apis in the world same same kind of idea these should still be serverless optimized apis so the hybrid framework is something like next gs or gatsby we're going to deploy the website and the functions together in one big thing and that's again this is a thing that we would do for convenience right so it's like hey that's all in one one thing we still get all the benefit of jam stack we have the functions there as well and we're gonna i still use serverless optimized apis right really powerful pattern i'm seeing this seeing that when used a lot these days well let's look at the static plus cloud okay so if we have some old school resources that we that we have already in azure or aws this is how we might want to take advantage of those okay so we have our static website that's anywhere again it's going to call bro use browser fetch to call a serverless function so like a aws lambda or an azure function and then it's going to use server fetch to call into our cloud-specific resources for again all the same categories of apis that might have been available you know on an edge sort of consideration but we're going to make sure that we're using resource affinity to call the ones that are that are near to it right so that means that we don't have to go outside a firewall to hit something like our sql server database here so like as i said it's going to be any static website we're still going to deploy these functions but we're going to do it separately okay not part of the same project and those functions are going to have close affinity to the cloud resources now you can mix and match these architectures right we could have something where it's like i have a nexus site where most of the api calls are you know in in the api folder of that nexus site but there's a few of these other other calls because i need to you know call into something in azure or whatever some other cloud uh resource where i have i could deploy those separately right so it's important it's like draw these things out lay them out on a white board or a visio diagram or some kind of some kind of chart where it shows you where these are and it can visualize it and see whether it makes sense and how you want to piece it together it's also important when you're when you're writing these things to draw out what the potential network addresses are right so one of the things that if i just actually go back a second to the hybrid plus edge example right so if we look at the browser addresses here when we're doing browser fetch from us from our static site to the service function it's going to be the same address in terms of like the the the base of our path right so it's like mywebsite.com api so like it can easily the javascript has permission to do whatever it wants there whereas if you're in the static plus cloud situation as here now we're going to have to make sure that we name our the the the website domain something that can call there so it's like you know www.mywebsite.com might be the static website we probably want to use like api.mywebsite.com to call the serverless functions and that can that can work with that okay so this is how browserfetch can have the capability of doing this now let's look at another pretty specific example we looked at databases let's dig into commerce a little bit because this comes up a lot so how does headless commerce or e-commerce work with this okay so there's let's take so you know it could be shopify it could be something like stripe or bigcommerce these all have very mature apis that we can use to call into the services that they have for commerce right so remember apis do not have a user interface they are a back end kind of a system right so we have our front end systems that we want to utilize so we have you know what gets generated at build time our static website so we can call you know we can get a list of our products at build time to get pulled in to combine with the cms content like from so in this case if i say i have a shopify store and i have agility cms for content that can be pulled together at build time to get all my optimized seo content that needs to be part of that static website at that build time okay so it's out there it's on the internet but at runtime what am i going to do well we can have a serverless function that can do the login so hey log into your account that's a that's a runtime serverless function type thing add stuff to your cart checkout do the payment those are going to be run with serverless functions now you might think well why wouldn't i just call directly into shopify to do those things if you did that you would need to expose your api keys and your secrets to shopify stripe or com bigcommerce whatever and you don't want to do that you want to make sure that those things are secured so you can secure those environment variables in a serverless function and then call into the other api and that's pretty much true for all of those api services that we talked about before so understanding you know at the beginning we understood hey where is my code running but now we've kind of learned a little bit more where should my code be in order to do to solve the problem that we're looking at solving and this is just the beginning of sort of understanding these architectures i really like to continue this conversation this is just the start of what i hope is you know a bit of a relationship get in touch with me follow me and my dms are open at joe vardy on twitter uh at agility cms is also good lots of great stuff about headless cms which is a really big part of this conversation too agility has lots of events and webinars that are there so jodysimas.com events i'm often there doing webinars with special guests from all different places including you know our friends from versailles netlify or gatsby as well among others but you can also you know old school email me joel at agilitysms.com love to hear from you this has been great you know get in touch let's do the conversation and thanks for tuning in

Channel: Agility CMS

Views: 273

Keywords: jamstack, gatsby, netlify, headless cms, cms

Id: 5U9JxBDtHew

Length: 22min 9sec (1329 seconds)

Published: Thu Mar 04 2021