Full-stack JS today: Fastify, GraphQL and React

So happy to be here. Thanks, everyone. I'll be talking about building a modern full stack application with JavaScript and a little spoiler, we're going to be talking about GraphQL, all open source, because that's what we love. My name is Cody, I work at NearForm, I teach web development course at the local university where I live in France, but enough about me. What I really want to do is I want to challenge everyone here, do a little exercise with me.

Close your eyes and imagine your next project. You've got all the requirements in from your stakeholders, you know what you want to build, and what are you going to do when you close your eyes? You're going to start thinking about those tools and those frameworks that you're going to reach for. When I do this, and I start thinking about those tools and frameworks, what I'm saying to myself is this time it's going to be different. This time it's going to be right, this time it's going to be rainbows, and this time it's going to be unicorns.

I think we all do that because we want to reach for new technology that's going to help, it's going to solve all of those problems that we had in our last project. I think the trap is, though, is we might get like 80 per cent through our project. When we reach that 80 per cent, all of a sudden something happens. Those real-world non-functional requirements hit that last 20 per cent, and it's that last 20 per cent that's really hard. Where do we find ourselves? We are thinking about rainbows and unicorns, we end up with something like this. I don't know how many times I've been like this, trying to fix real problems in a production application. We've got complex CI pipelines, we've got problems with scaling, we've got problems with performance, security things we didn't think about in the beginning, authorisation, authentication, so I feel like there's this massive gap between what we imagined and the reality, because we are all just real-world people fixing real-world problems. We're devs, we're trying to do the best we can, and I think what I want to challenge us to do today, let's focus in on that last 20 per cent, that hard 20 per cent that we don't always think about in the beginning.

So, I want to talk about this guy. This guy, his name is Vilfredo Prado. We call it the Prado Principle. I know you can't read that text but you will in just a second. Vilfredo Prado, this Italian economist, he came up with the idea of the 80-20 rule. I keep talking about these percentages and he said, you know, like, maybe just 80 per cent of our outcomes in our projects are going to come from 20 per cent of the challenges, of the requirements. That's what I want to challenge us to do today. Let's think about that 20 per cent from the beginning. So there's the Prado Principle in its entirety. And I think Steve Jobs knew this. When he came back to Apple in 1996, they had like 15 desktop computer models, he cut them down to one. They had a whole bunch of portable devices, I think they called them laptops back in 1996, he cut them down to one. Peripherals, printers, deleted them all.

Got rid of them all. He wanted to focus in on that last 20 per cent, that last 20 per cent that really mattered. So today, what I want to focus on, what I want to challenge us to focus on is that hard 20 per cent. And maybe, just maybe, we can gain 80 per cent in our productivity.

So how can we build this tech stack, this magic tech stack, that's going to focus in on that hard 20 per cent, that 20 per cent of non-functional requirements, help us get speed of delivery and ensure that our production-grade application can work the way that we want, that we can fix things while it's in production? To do that, I want to lay out some principles when I'm going to build my tech stack. These are the principles I'm going to think about. The first one's going to be modularity. And I think one of the challenges, the traps that we can fall into, is we're going to reach for that framework that says it does it all, and we think it's going to do it all, but maybe it doesn't do it all. What happens when we hit that moment when it doesn't do something we want, and we have We have to reach for something else, or throw away the framework and start from the beginning. So if we can build a tech stack where we can swap out layers of the stack when something isn't working, we've won something, right? Like our stack suddenly becomes modular and we can adapt to the situation, to the requirements as they evolve.

Next up on our principles is going to be developer experience. That's why we're here. We're all devs. We're all fixing real things. I want the tools like help me, like guide me, not get in the way, right? And I want to be able to run my application anywhere. I want to be able to run it on my laptop while I'm in the train, when I don't have Wi-Fi or the airplane, like it needs to run locally or in the cloud, on site, docker, whatever it is. That's really important to me, too. I don't want to be reliant on some cloud services and I can't run my end to end tests on my machine because I'm reliant on that internet connection that doesn't exist in the hotel. Based on my principles, it's community first. I'm talking about open source projects. Community supported. They're going to be more secure, ideally, right? Because more people, more eyes are looking at the code. Bugs are going to get fixed. Things aren't hidden from you. I think that's really important when it comes to a tech stack. I'm talking about a hundred percent open source. Not just that 80% and 20% of the magic secret sauce is running in a cloud service that nobody can see. I want to see 100% open source. My next and last principle is going to be transparency. This is related to open source and that idea of a community supported project.

Also transparency, when we talk about abstraction. We love abstraction layers. That's what makes our lives easy. That's what makes us productive and develop things fast. What happens when abstraction doesn't work? I want to be able to peel off those layers and get my hands in on the nitty gritty. The dirty parts. Like we saw in that first meme of people fixing things. I want to be able to reach under those abstractions if I need to. They shouldn't be hidden from me.

So let's talk about the stack. Now the stack. Most people when we start building a tech stack, we often start from the front and work our way back. I think that's the wrong approach. If we want to fix that last 20% of the non-functional requirements, then we should start from the back. That's what I challenge us to do today. So I'm going to turn the whole problem upside down, inside out. We're going to start from the back. So let's talk about the stack.

You're going to see this slide with the waffles quite a bit. I found them to be pretty tasty. So we'll see that often in this presentation. So first thing on the stack, we start from the back. You can flame me. You can send me your hate mail. You got my Twitter handle there. But my friends, there's an elephant in the room. And the elephant's name is PostGrey. Why would I talk about PostGrey? PostGrey is awesome because relational databases, I also love document-based, no schema databases. But devs know it. And I'm willing to bet in this room, anyone who has a computer science degree or software engineering degree, I bet you've taken a relational database course.

I'm willing to bet money on that. So devs know it. You can add devs to your project without a lot of challenge. And I think that's really important.

Next up, I'm saying it right now. Quote me on it. It's the best relational database. Not only is it the best relational database, it's also like no-SQL ready because they've had JSON support, I think, since version 9, and we're up to like 14 is the current release. So the JSON support just gets better and better. So if you want to build a document-based database, you can do it in PostGrey. That's one of its superpowers.

Sports connection pooling, I'm not going to spend a lot of time on that. I need to speed up a little bit. But connection pooling, we're going to have insane scaling. That's another thing we have to think about when we're building that big tech stack. So we can do connection pooling, we can suddenly cut off tons of resources doing the TLS handshaking if we can share connections. And last thing I want to talk about is that dev experience because I can run PostGrey, I can spin it up on my laptop here in like a second in a docker container and I can run all my tests directly. And, you know, love it, hate it. I have that relationship with SQL, but it is crazy powerful. aggregations across multiple tables, or if we were talking about collections in a document based database, I can do it.

Next up on the tech stack we're going to talk about the server. If we're going to talk about the server, we're going to be talking about Fastify. I just couldn't help but thinking about that Fastify cat eating some of those waffles. This is my node.js server and it's inspired by happy. It's going to be really familiar to anyone who's used Express before. It's easy to use. And what's amazing about happy, Fastify, is that it allows you to build a monolithic application today when you're doing your POC. As your project grows and your requirements grow, inevitably, you're going to want to split that up probably into services, create some sort of microservice architecture, and Fastify, with that plug-in architecture, it's going to let you evolve with your code. So Conway's Law is always going to come into play. Essentially, your code is going to look like your organization, and Fastify lets you do that.

It's open-source, it's transparent, and it's modular, because we have those plug-ins. Again, it can run anywhere. That's one of the things we love about Fastify. And that plug-in architecture is just kind of programming Xen when each plug-in is isolated from the others, and you can logically build your application.

So now let's get to the good part, our API layer. It's going to be GraphQL. If we're using GraphQL on the server of Fastify, we're going to be using Mercurius. Mercurius is a GraphQL plug-in, a GraphQL server for Fastify. And it's going to solve real-world GraphQL problems today, like out of the box. This is what's so cool about Mercurius. It supports caching, federation, authentication, subscription, file uploads, all those things you didn't think about when you wrote your first GraphQL server, it comes with those in the form of a plug-in that are supported by the core project, or it comes with them out of the box. That's what's so amazing. And the caching, we're going to talk about that in just a second. The caching is really amazing in Mercurius, and that's what's going to give us some amazing performance as our application scales. It integrates the GraphQL server, so we get a timeline where we can see our queries going by and we can debug them in our browser. Oh, sorry, that's the next step, I skipped a step. That's to allow us to debug our queries in our browser as we're building them. It has loader support built in. I don't have time to go into that. Inevitably if anyone here has built a GraphQL server, you're going to have that problem where your data is in a graph, so you have some sort of hierarchy to it. If you're fetching parents, eventually you're going to have to fetch children. You don't want to do one after the other. You want to queue up all the parents and then queue up all the children and maybe do two queries to your database to get all your data. And loader lets you do that, and that comes built into Mercurius and that's one of the things that I love about using Mercurius.

We're going to switch over to the client side. If we're going to use GraphQL on our client, what are we going to use? We're going to use Urql. I call it Urql. You might call it U-R-Q-L. U-R-Q-L. I think Urql has a nice ring to it.

It is the best GraphQL client. It's going to work with all the major front end libs. We're at React, so it supports React as its principal front end lib. Caching. It does some crazy caching. cache things using your query as the key into the cache but can also normalize your data and cache things by ID, ID of the entity. This lets you pull items out of the cache that have already been queried by a different query. And you've got offline support. If we have the ability to store things in cache, we can store it in the index DB in the browser and our application can suddenly run offline. All the things that we might want in a GraphQL client, Urkle has that out of the box. And, of course, it has a hooks API. We're here talking about React. It's a magic API and they have some dev tools.

So had to throw in a couple of code snippets. This is really one component, but I split it into two segments to fit it on the slide and we'll build a pizza application. I'm going to have slash pizzas in my application that's going to list all my pizzas. I'll probably have, like, slash pizza, slash an ID, to get details. So this is the list. And we have that use query hook. I guess I have my query on the left. And in the top of my component, I have the use query hook. And that returns a result object which has these three keys in it. Data fetching error. This is amazing because, like, the API is built for writing React components. So if there's an error, I can show one thing, pop something up. I can have a loading spinner. Super easy. And finally, I can actually render my data. And if I've configured my cache correctly, if I run that query, and now I'm going to get details for a pizza, I have a similar query on the left. This time I'm going to get it by ID. If I've set up my cache correctly, you know, my component looks about the same on the right, you just have a little different query. Suddenly, like, Urkel lets us get the data out of the cache without having to go to the server so I'm going to visualize this very quickly here. So I have two components on the left. My pizza component and my pizza component. I'm going to make that query. It's going to work its way down the database. It's going to come back. But things are going to get stored in the cache. So now what's going to happen, though, if I've set up Urkel the right way, when I finally do that query on the client, it's coming right on the cache client side. No trips to the server. And this, this is amazing because if we, like, set up our GraphQL APIs to match our business domain and we can store things in the cache, like, imagine if, like, we don't really need to worry about application state, like, global state, redux, all those things can make our application really complicated. Had to throw this in there. Like, this is how I feel when I don't have to write redux code.

Every day I feel like that when I'm not doing it. So, of course, we're here at React Summit. Gotta talk about React. Why do we love React? Well, because it's React. And we're all here, like, devs know React, so you're gonna be able to ramp up your team, add resources. That's one of the things we love about React.

It's always evolving but, yet, it's still stable. Okay. 18 had some changes that all shocked us, but, like, we were ready for that, right? Components make us architect our code in a good way. Dev tools, we love it. Vite. If you're not using Vite, use it. Go check it out. Yeah, if you're not doing it, just do it.

So, honorable mention. I'm running a little short on time, but honorable mention here is gonna be SSR. Like, we have to talk SSR a little bit. Now, what's awesome, if we're using Fastify and Vite, there's a little plugin for Fastify called Fastify Vite which lets us do SSR, so suddenly we have a full stack where we can do SSR and each component is modular going back to those principles. Works with all the major front-end libs. It's going to handle the page-level templeting and it's going to integrate all those routes that you probably have in your React router. It's going to add those into the Fastify server so we can map our client-side routes into routes on the server. I'm just going to go really quick here, if anyone wants to talk about this with me, we have a booth, a near-form booth out here, come see me and we can talk about that in more detail. It's customizable, it's not magic, it's super transparent. An honorable mention, my colleague Jonas Galvez, he just released Fastify DX which is going to have React and Fastify Vite all set up, out of the box, ready to go, check out this project, if you haven't, it's still kind of in beta. He just released it, I think, two weeks ago, and it's going to be out of the box, having everything set up but in a transparent way that you can customise.

So, when I started the talk, we're talking about unicorns and rainbows. Maybe we can't have both. If we start thinking about the problems that we're inevitably going to have in a production application, those non-functional requirements, and we build those into our tech stack from the beginning, we can still have unicorns. We may not have any rainbows, but I've still got a unicorn. So I just want to review this stack super quick.

Why would I use this stack? Like I said, it's built for that complex functionality, those non-functional requirements that are going to happen at the end. That last 20 per cent, we're thinking about that from the beginning, it's highly customisable, we can swap things in and out, still has that modular design.

All the abstraction layers, they're transparent, we can peel the covers off, we can get our hands dirty if we need to, and of course it is a community... All community-supported projects, open source, got lots of eyes looking at them.

So that's why I would use this stack, and that's how I sell this stack to your team when they're reaching for that framework that claims to do everything. I just want to real, real quick, ask you all a question. We had the lean stack, we had the mean stack, we had the jam stack. What's my stack called? The best we could come up with is Frump, Fastify, React, Urkel, Macarius, Postgre? Doesn't really have a ring to it. I thought of like firm or merf. Those are a little weird too. If you have any ideas, send them to me on Twitter or come see me at the booth. I'll be happy to talk about that.

I work at NearForm. Like I said, we do have a booth. We're the maintainers of some really important open source packages and MPM, and we do professional services, but we also get to work at open source and contribute to open source. Awesome place to work. If you want to know more about NearForm, hit us up at the booth. Be happy to talk about that. I built a proof of concept, that pizza app. You can check it out at this URL. You can also see my slides. And if anyone has questions about these things or they want to go into deeper details, I'd be super happy to do that. Come see me at the booth or hit me up on Twitter. Thanks, everyone. Thank you. Step over into my office. Into the office we go. That's nice. First of all, I do have a bit of a bones picker view here. So much amazing food in your slides, you make me hungry.

Well, it is about that time, right? Nice. Let's jump into those questions. Remember, if you want, you can also come find him at the booth and also in the Q&A booth right after this. But let's jump straight into that question. Let's do it.

The top one. Is it possible to use Fastify in a serverless infrastructure? Because this is something I'm always trying to do things serverless. Absolutely easy. The answer is yes. It's a big yes. Go to the Fastify website, and they have a link right on the home page serverless, and they're going to show you how to set it up. AWS, GCP, Azure, whatever your service platform is. They have directions to set it up in all of them. Perfect. So big yes. Awesome. Awesome.

So let's talk about the advantages of two, of Ercu and Mercurius versus Apollo, and let's just combine them into two. What are the advantages, disadvantages of the two? I don't want to criticize any of the existing frameworks, but what I love about Mercurius is that it comes with all those things, those little magic bits that we might not have thought about when we're using the other frameworks. It comes with those built in, out of the box. So the moment we need to do federation, or the moment we want to do authentication, or adding caching, it just comes out of the box. They gave it to you, it's right there in the readme, it tells you how to set it up. So those are the things I love about Mercurius and why I'd work with that.

Nice, nice. And Ercu on the front end, sorry. Nice, and a lot of people who have used so many different types of stacks, I'm always trying to compare them, let's just talk about some of the cons and disadvantages of this stack so that we can evaluate it with others. Yeah, I think that's a fair question, I think that's definitely a fair question. The disadvantages are maybe it's that initial development velocity, so if we reach for a framework that claims to do it all, it's going to launch us super fast into a high development velocity, so I think that's definitely an advantage to a big framework. But what I want to caution everyone is to think about what's going to happen once it goes in production, once you start having those other challenges when you got to fix things in production-grade code, are you going to be able to do that when you're using that big framework? There are advantages and disadvantages, I think maybe if we spend a little bit more time in the beginning, we can save a ton of time in the end.