Keynote on Next.js and Serverless future – Guillermo Rauch

[Music] um [Music] [Music] my name is guillermo rauch and i'm the founder of zeit and the co-creator of nexjs the easiest way to create a react-powered website or application i'm tuning in from california and i'm really glad to virtually meet you so today i'm going to talk about a topic that i'm really passionate about which is creating websites and applications with react but placing them at the edge so that you maximize performance you maximize availability all of this with the best possible developer experience so at the end of this talk you will have learned why it makes a lot of sense to put your sites and apps at the edge why it makes so much sense to go global how you can reach more audiences faster and how you can do so with very very little overhead on your side and you're going to do so by learning how to architect applications and websites such that you can deploy them to the edge so as developers really have one task at hand and this is the manipulation and orchestration of information systems in particular what i mean by information systems is any physical system that involves the transmission of information over time and space and just like any other system out there it's governed by fundamental laws and chance these fundamental laws have to do with the transmission of information which as you know is not instant so when you're talking to me or watching me now we're conveying our information stream over time and space and obviously that takes time so on a very very abstract way our job has to do with this transmission of information to from point a to point b and point a tends to be a data source and point b tends to be a human brain so you can think of point a being a website point b being me and go to that website in other ways you can think of more generally as me conveying an idea to you but usually with the systems that we create there's usually a stop gap we push information somewhere and then that information is later pulled by your users and there are two fundamental mechanisms that we deal with as application developers that deal with these information systems on a day-to-day basis one of them is push so you might think of push in basically opposition to pull so when you think about a system that pushes you typically tend to think of a system such as a mobile phone that gets a push notification and while this is a super fascinating pattern it typically doesn't have to do with the kind of websites and apps that we create with react obviously when we're creating websites and applications we typically are creating pulse systems and what i mean by this is we create a react-based ui and then some user goes to that website and then pulls the information right so there's an act there's a discrete action that involves requesting a piece of information and then i expect that data back to come to me as soon as possible so in terms of the pattern that we thought about earlier is i'm going to get some data and one in my brain as fast as possible so the uis that we're building and the applications and website we're building increasingly more global so when we think about the growth of the internet at large and when we think especially about the relative growth so the chart on the right hand side is describing what happens year over year in terms of how many users are being added relative to the year before and you're probably seeing now a lot of locations that are not particularly close to your home now that react summit has gone online we'll probably have some more but these are probably not the places that you're expecting when you're for example uh writing or reading a tutorial on the internet says okay i'm going to write my first application where is my next user likely to be well increasingly these are not always closer to home and when you think about even e-commerce um i'm based in the u.s uh react summit was originally going to happen in amsterdam we think okay us and europe these are not necessarily places where e-commerce at large is growing with that kind of relative growth year-over-year so we find asia pacific and latin america in terms of inner growth at large we have trouble hearing you we find that india added 100 million users in 2019 followed by china actually then followed by the us but then many other countries that we tend to not expect as as obviously to be on this list and in particular the times that we're living in today with this pandemic have shown a very very strong need for this instant connection this instant information acquisition to happen uh the winners of this pandemic have actually been those who have engineered with this global mindset uh ahead of time so much has been said about zoom for example and how well they've scaled and how well they've performed when they've added or 10x or 100x their user bases very very quickly over over the past few months and years and this is no coincidence because they thought about being global from the very beginning so they operate data centers in many parts of the world and their applications interface with data centers that are located automatically by the client application and optimize communication around that initial user location so when we think about the patterns and when we think about the rules that i've already described there's not much we can do about them right so there is the fundamental loss of the universe and how fast fast information can be transmitted over back vacuum and over a wire and then on the other hand we have the rules of the global economy and the rules of this demand for more and faster global connection so we have to play by these rules we have to accept them and adapt so if we think about our job from that perspective really is to transmit information as fast as possible and i would say to spark joy at global scale and i particularly added this because there are many ways in which we can mask latency and do interesting things with javascript on the client side and react to provide pleasant interactions that go beyond just a mere transmission of information so i would be describing an incomplete model if i forgot to mention that techniques like animation and transitions and spinners and color and ways that we can mask latency those obviously help so the task at hand is to deliver information quickly and do so in ways that are pleasant to people and obviously respective of their privacy and of their needs and demands so when i think about the tools that we have and how our tools have evolved i've i would think that the most important thing is that our tools i have adapted and evolved to consider these rules that of this global landscape that we just went over so the tools have to adapt and rise to the challenge and an interesting observation that i've made over time is that when you think about how we've been doing software development it really does feel like we would we've been confined to a black box so i would suggest that our challenge moving forward is to escape this black box so start with wise is a black box and in the first black box like experience that i think about is our local development environment so how do we develop software starts with an illusion so we have localhost 3000 so anytime you sit down to develop an app you put up into this illusion so to speak so and i mentioned that specifically because localhost is not a accurate metaphor for how this global internet in this global world and this global information transmission networks will play out so it's a simulation that for the vast majority of that experience hides and runs away from this reality in some substantial ways for example obviously we're dealing with one location we're dealing with assets typically that are unoptimized when you boot up your development server whether it's nexjs or create react app or review you're basically putting up into a different reality there's no ssl which in some cases causes browsers to turn up features there is um no optimization or modification or regulation or compression of the code the the the different ways in which assets are loaded are not comparable to how they're going to be loaded in production so this is kind of how this black box starts to begin with so funny enough we created this local dev servers and then we kind of said okay so there has to be one way that we're going to represent our applications universally right so like if it runs on my computer it should run somewhere else and so kind of the best idea that we came up with is to to ship the black box so um the black box as it works in your machine obviously it's not accurate to say that you're necessarily shipping your dev server you're optimizing the assets a little bit and they're saying okay run pretty much the same thing somewhere i don't care just you know here's the black especially when you're working with someone else and like you're like here's the deliverable here's my little server box let's ship it and this is kind of where this metaphor starts showing and some of the problems that we have right so typically when we ship this box or container server whatever we think of shipping it to one discrete location in the world okay it's like right ship it to san francisco so the development life cycles are being developed built in the process of building interestingly we produce lots of assets and i'm going to dive into this assets assets a little bit in a second because they're very very important we take the assets we put them back into this we assemble this box and we ship it to san francisco and i mean san francisco because a lot of startups tend to just you know start there and put their servers there it could be virginia it could be somewhere else and like i said this this idea of what the outputs of your application are tend to be very important specifically the ones that are you know just the basic fundamental primitives of the world or the building blocks of of the internet uh which are html js and css uh kind of following or in some ways in parallel but following this trend of you know building this opaque black boxes or containers and new ideas started emerging in our industry which is jam stack so jam set had this simple proposition that j am use your site or app can be fully static markup so you can take that html and say you know my site and all of its entry points are going to be that static markup and then you take js but you run it on the client side you don't run it in in a way where in that particular location that you ship your code to you're mediating the responses with that js code for example no you're assuming that the js runs in what i call the true edge which is ultimately the device and then you call apis from there if you unwind a little bit you're you're probably and if you like zoom out and squint you might think that there's kind of an interesting peril here where jam stack and the ios development model kind of resemble each other because when you download a native app you're probably downloading it from the android or or ios uh edge kind of storage system you're downloading some code you're booting it up and you're querying some apis so jamstack kind of presented this new alternative for how to build kind of the same things and one really interesting feature that i particularly think is very much worth paying attention to and it relates to this idea of saving and shaving time is that because you're shipping assets fundamentally and your application is broken down into this assets and as i mentioned there's no server that intermediates the communication between your user and your application a lot of the things that were being done just in time like acquiring data and rendering html that was being done just in time because you were going to a server that server was going getting some data and it was outputting it to you that was being done just in time so what we've realized collectively is well is there an opportunity to do some of those things ahead of time so the obvious idea there is why don't you request the data at build time inline it into the html and ship it so that then by the time the user comes to it the data is already there so it was done ahead of time and what's of most interest is that we kind of are starting to remove this boxing a step of the application delivery process interestingly enough the construction largely remains the same right so we develop we build we output html and css and js and some server code that will we can talk about how we can model that in in this world and then we ship it but not usf we ship it to the world and and this is where shipping re-adapts to the edge becomes really really interesting so if we unwind a little bit and we think about what nexus looked like three years ago it kind of embraced this black box development model right because you would run next build and then that gave you that little package that little box and then you would start it up somewhere and most likely you would start it up in in that cluster location region that you chose and this kind of worked right like you can say well you know there are ways that i can speed this up there's ways that i can improve that fitness function that we talked about earlier of like if i'm a visitor i want to get the information as soon as possible and that's by using a cdn right so like i can use a cdn and that means that i can take some of the things out of that black box and depending on like juggling headers and so on put them at the edge so my answer to that is that yes to some extent we were able to do that and they may i mean some of us were able to do that some of us would sometimes forget to do so or you know configure headers and things like that um but there's still a fundamental disadvantage right so like you think of a cdn and i represent it here with like different clouds all the points of presence that it has globally and then you think about your users coming and hitting those points of presence when an asset is fresh when you just wrote code when some something new was created what would typically happen is um you're hitting a cash and that cash could have already evicted you or might not have your asset or because whether you just wrote code or for whatever reason and then what happens is when this misses of this cache happen we all go to this central location that we're deploying this black box to and again this is kind of a still the best case scenario for this model because this assumes that you took the you did all the job all everything correctly like setting all the you know cash control primitives creating your purging pipeline synchronizing everything ensuring your cdn works perfectly and what's interesting is you know i was i started to collect experiences in which i go to a website on my phone or on my desktop and it's and a website i would expect to be fully static it is a static it looks decided it feels static it's nice it's just a marketing side and i get this errors sometimes that say you know bad gateway or we could not communicate to the server and start thinking about like what server why were you communicating to a server to begin with and this is kind of where this like black box uh application model starts showing its limitations right so we have the issue of slow trips to home we have the issue of potentially overloading your back end we have the issue of the developer having to you know communicate back all this cash control primitives and then ultimately you know we are not taking advantage of how we were building that application and our framework is being conversely naive to all the interesting optimizations that we can do with modern cloud primitives um so jamstack is not just about really how you were you know what code you were using but it's also this realization that okay if i can make parts of my application static that perhaps should be static and what about even making your entire application static so with net js we looked at you know the incredible potential that this could bring in terms of the developer not really having to think that much about okay i need to you know jam stockify or things like that so we looked at ways that we could embrace this idea and what we came up with is we already had a very powerful page-based application model so for those of you are familiar you know that you create lots of pages inside a pages directory and then those automatically mapped to routes not unlike how kind of php works and what's interesting is now we can kind of take each of these pages and we can say you know how is the data being required for this page and we can say for example no data is being required at top level like in this case we can see with this um top level page and this by the way is kind of a a mini version of what our website today zai.co looks like first of all it's all inside one repo it allows me to share components across all my pages my slash page is my home page and i don't want that to ever be down or slow fully static obviously um i have a function there and that function needs to execute code on demand definitely so what does next.js do if you're creating an api page pages slash api such as cell.js we export as a serverless functional lambda function our dashboard interestingly enough is also static but it's a static in a way that feels very much dynamic because again we execute runtime js code we boot up we issues effects with react hooks and we get data and interestingly our blog is also static but as i mentioned earlier we made some ahead of time optimizations so what we do is for the dynamic path segment that you see there post we say okay data store tell me all the posts that i have to generate with this as you see on the bottom get a static paths hook and then for blog itself we say okay let's get static props add build time at the end of the day what do we get we get a bunch of assets mostly html pages and also a function that can now be pushed to the edge and by the way static is only the artifact as i said you can put up to js in the client side that enhances these pages so the black box is now open and i can take these assets and place them strategically either next to my users or next to my data sources no need to set headers again if you look at the title of the presentation i said you know you can be performant available developer experience pic3 so as a result of this better architecture the developer experience and the deployment and devops experience also improves because i don't need to configure anything the static parts can be hoisted the purging is automatic and functions can be co-located next to data sources and typically what happens as a result of adopting this architecture is that the actual maintenance and overhead that you have to do over the deployed artifacts is basically null because again your application is just this super stateless super simple super static asset set so the artifacts are deployed to the right locations the static ones can be replicated globally by our edge network the functions can go to where they make sense to be in right in the prior iteration of this arc of the architecture that you could create we're thinking of this local server that you know assumed the database has absolutely to be next to it otherwise lots of ranchers will be slow the static assets also inside all that together with your code and your you know server code your authorization code so not only are we getting um the flexibility now to collocate code as a tr strategically next data sources but the static assets can be liberated and break out of that box so as a result we're gaining in so many different dimensions right we're reducing latency we're improving availability we reduce the single points of failure we reduce the time that it takes to acquire this assets upon a cash miss from the global edge network and we remove all together the need to ensure that that server unit or black box how to scale how to stay up and so on and the interesting thing about this is that we've done this kind of strategically in such a way that you can think of adopting this architecture one page at a time so yeah if you've tried or or want to dig deeper into this kind of the next first step is you run create next app with mpx you'll get up an index.js page that when you run next build just becomes a static and obviously the only contract required there is that you export real component then you can create pages that become more interesting that have dynamic routes even in the route in the url but also get data at build time this is where you use the hooks get a static props and get aesthetic paths and then you can even have functions that execute tiny bits of server code that can act as a glue to existing backends or databases and this ideally can be called from client's ijs from within those static pages that i mentioned earlier and the contract there is very similar to what a express um endpoint would look like where you get a request obviously a response object if you want to go step by step and learn more about this i suggest you go to nexjs.org learn and once you have that repository or where you have your next.js app or even any other static or jam stack app or framework you can import it and then deploy to the edges as easy as running get push and as i mentioned earlier that illusion of just being constrained exclusively to localhost 3000 disappears because what happens is you have your repository and your you can obviously develop locally while you're iterating but what happens is after you push because this jam stack architecture is so lightweight we can afford to take this static axis and kind of like every get push becomes its own accessible website that it gets exposed to the world so those limitations of not being able to actually test what that thing that you're creating feels like in the real world environment kind of vanishes you now get this url that you can run performance tests against lighthouse tests against um all kinds of stress tests against and actually understand how it's going to perform in this real world scenario of being co-located at the edge um thank you so much uh for um bearing with me through this presentation um i'll be obviously following up with any any for any question that you have you can go to nexus or slash learn to learn how to develop these applications or websites and then zy.co to learn how to push them to the edge and deliver faster better websites thank you so much wow guillermo thanks for that great talk uh really learned a lot from that um yeah super happy to have you here uh for our first q a session so hi thank you really excited to be tuning in yeah you look a bit tired you just woke up probably it's super early in california yeah i can imagine i can't imagine so um one question i have uh you mentioned that uh there's a lot of progress since the 2017 version of nextgs indeed if i if i can make an analogy uh if a 2020 next year next yes app hosted on site would be for more formula one car what would you say a 2017 next year app next js app would be that's that's a very apt metaphor i do think just like um a formula one car we've been working a lot and improving the engine but also just like formula one cars we're adapting to the rules of the environment constantly right i don't know how much you know about it but uh the regulations and rules are constantly changing so the environment is a very dynamic one so you have to adapt the technology of this environment right and really what's happened is the environment has evolved right so in my talk i was describing how the rules are kind of these global rules right and the expectations of developers nowadays have evolved with this environment as well so with gemstock the demand has really become let's optimize very very strongly for the front-end experience whereas in the past we're kind of being a little bit more holistic more full-stack more server oriented right so nowadays the environment has really shifted towards let's push content to the edge let's do more ahead of time rather than just in time so i would say you know uh it's my baby in some ways so it's it's uh it's always been my number one formula one car um but i would say that things have just gotten dramatically faster and the very nice thing about nexjs is developers haven't really had to adapt their code much a lot of the uh improvements have gone into that build process that we talked about right so um yeah it's like really driving a formula one card it upgrades itself so um we've we've done all this work around you know maintaining great backwards compatibility so as long as developers are upgrading xjs9 they're really getting our best engine ever our best car ever okay so to sum up it would basically basically be a 2017 formula one car yeah plus three years of improvement that you just like download from the cloud basically yeah which is pretty cool well thanks for the great work uh i'm getting a question from slack for the people watching you can still ask questions uh we have a few minutes left so if you have any questions drop them in the slack channel q a dash react dash track there's a question from ro how does this compare to using a pwa then it's not just hosted at the edge it's literally hosted on the device great that's that's a really great observation really um what we've always wanted to enable with nexjs is react on the client side right otherwise we would have thought we would still be stuck in the past with like templates and server rendering and like you know dropping a script tag and loading jquery on the client side so the spirit of next.js has always been hey you can do some work ahead of time like with static site generation and the build process but really it's all about enabling developers to do interesting things on the client side right we recently launched our swr hooks for data fetching on the client side so you can check it out as wr.sh and tanner is going to be talking about react query so ninjas has always allowed you to embed these components that are specifically designed for enabling experiences on the client side enriching your websites on the client side so where does pwa fit in in all this so i would say pwas do less of this ahead of time optimization so you're not pre-building content you're not building your blog or a marketing website necessarily as a pwa pwa has really fit more the context of like you know the twitter client where when you load it you load into a splash screen and then you're doing things that are very much on the client-side spectrum and pwa is giving you features like service workers to really piggyback more on the device capabilities but the really neat thing about nxjs is that it's always covered that spectrum so the number of features from pwa that you want to take advantage of is really up to you and i would say that the investment on what pwa features you're going to choose is going to be very domain specific so some apps it makes a ton of sense to add lots of pwa features some are more on the website spectrum nexus has always allowed you to create both which is really great a great example of adding a cool pwa feature to an xjs website is adding notifications so you create a blog and you want to push updates to your clients you can use pwa features there as well and i think i like this question a lot too because i do think that what we're going to see a lot with jamsec is this ability to transfer a lot of compute to what i call the true edge which is a mobile device so if you can do computation on the device then that frees up resources that you could be doing on cloud and also speeds up it get a latency benefit as well right because you're giving the client even more responsiveness so throughout 2020 we are going to be investing a lot in even deeper integration for pwa workbox and other associated technologies like offline first websites into nexjs so uh i really recommend staying on top of of what's uh what's going to be announced cool well great answer thank you um the next question is from andreas wrote somehow i feel that the persistence layer is still not up to these new jam stack requirements am i only not update today here or our solutions like founder debay or cosmodb not as intuitive as services like site or netlify yeah i would say that's a good question i think data layer uh is always a tricky a very very tricky uh question um we've been talking a lot about you know like what just now what data belongs on the client side what data needs to be persisted directly on the device before it synchronizes the cloud there are patterns that are more fitted for back-end oriented architectures where you just make a remote call and that back-end interfaces directly with the database i see this as a spectrum so the easiest way to get advantages from a modern front-end framework like nexjs today truly is that there already exists an api whether it's rest or graphql and you're really modernizing your front end layer and then you're pushing that front and layer to the edge that's what i think i i would say almost a low-hanging fruit of the internet is today because if you look at the past 10 years of software engineering we have been working toward this separation between back-end and front-end already and again that was driven a lot by the rise of mobile so the rise of mobile meant you know we're going to create native apps for a lot of companies um or even also the rise of the api as a service like stripe and other companies right that meant that a lot of companies were already exposing apis they were modernizing their backend infrastructure through rest or graphql so that creates an incredible opportunity for front-end developers that are watching right because really you can take a framework like nexjs and you can completely overhaul your front end experience so you can modernize it with react components you can implement design systems you can make transitions really snappy because you're piggybacking on device capabilities one of my favorite device capabilities that you can take advantage of with nexjs is the local in-memory cache right so the back button can be instant transitions between pages can be instant all that is enabled because next.js is a very powerful also client-side framework so that's where the low-hanging fruit is right the back-end already exists i'm going to take over the front-end experience i'm going to add pwa features i'm going to add real components et cetera et cetera now what the question is asking is what are the opportunities to start going into the modernization of the back end as well so i would say that today nex js is giving you a little bit of that a taste of that future with functions right so we added built-in capabilities for defining serverless functions so this serverless functions can act as glue between those back ends that maybe already exist in your front end so it kind of is giving the front end developer this extra power a little bit more extra flexibility to really not be stuck waiting for you know backhands to improve or file a jira ticket to your backend team and and so on and so forth it to just get some new capabilities so what does the future then look like for people that want to do more than just talking to existing backends and now talking to databases all together and that's what i would agree with the question that it's a little bit more tricky and a lot depends on what the ideal database is for the problem domain that you're having right i do think we're going to see kind of broadly two trends there is one is graphql where front developers feel very comfortable right because it's very much optimized for their experience and then we're going to see i think also databases that are more optimized for talking to functions directly right so we're starting to see aws put out some products for optimizing you know databases for connections with serverless functions i think we're going to see a lot more of that but i'll reiterate that i think really the power for the front-end developer comes in just owning the front-end experience and and then try to push that to the edge so that the database doesn't really matter at that point okay okay oh great answer uh we have a few questions left but unfortunately we have no more time so for the people that are asking questions in slack please go to the speaker room in zoom with guillermo guillermo i would like to thank you for your time and enjoy the the one-on-one talks with our attendees in the zoom room for it thank you so much bye-bye

Channel: React Conferences by GitNation

Views: 5,193

Keywords: javascript conf, react native, js, react conference, react amsterdam 2020, js conf, development, ecmascript, graphql, react conf, react amsterdam, javascript, react, reasonml, javascript conference, remote conference, react europe, jsconf, react rally, online webinar, web-development, reactjs, react europe conference, react summit, online conference

Id: 2porsQ1gLvA

Length: 39min 7sec (2347 seconds)

Published: Mon May 18 2020