Killing BFFs with GraphQL and Next.js

Hello, everyone, and welcome to my talk, Killing BFFs with Next.js. I guess it's almost Halloween, so that's a great way to start out with some Halloween opening.

So Killing BFFs with Next.js, but it's not a Halloween talk, but it is something that is probably interesting for most of you. So what is this talk about? Let's start out about... You probably already know about microservices or maybe you're still using a monolith. You also have BFFs and monoliths, but those are a bit different.

So imagine you have microservices and then you have a backend for frontend for your web client, you maybe have a separate backend for frontend for your mobile client. So this is probably perfectly fine, but it is something that takes a lot of extra work for your team and maybe also for your backend developers because they need to make sure the microservices are tailored to two different backend for frontends. So that's something we are discussing today in this talk. So I hope you all enjoy and if you have any questions afterwards, there's some time for Q&A.

So backend for frontends is... Well, it could also be this, when you and your backend for frontend know something nobody else does. So this is actually a problem because your mobile client may be doing something with their mobile backend for frontend while the web client wants to do the same thing, but maybe the logic isn't implemented there. So backend for frontends aren't only a way to make things easier for the client. They can also lead to extra complications because maybe one client knows something that another client doesn't.

So a little bit about myself. So my name is Roy. You can find me on Twitter with my handle at GetHackTeam. I'm an entrepreneur, a software engineer, but I also I've written some books and a regular speaker at conferences. So if you don't know me already, please find me on Twitter. Currently I also work with a company called Stepsen. What they're doing, they're making one unified GraphQL API for all your data sources. So that's pretty cool if you want to get started with GraphQL. And also I give workshops and trainings to my own company Hack Team, so make sure to go to the website as well if you have questions about that. But also make sure to just enjoy this talk and try to learn something new.

So how do we go to back-end for front-end? So back-end for front-end or BFFs, as I already said, how do we actually get there? So I think the first time most of you got in touch with API for the first time was with monoliths. So monoliths are, as they say, one API to rule them all. And monoliths can be REST APIs, they can also be GraphQL APIs, maybe even SOAP if you started web development or development in general a long time ago. So monoliths are basically one API to rule them all. And if you're working with different clients from our monolith, typically you would have separate REST endpoints or if you're using GraphQL, which can be a great way to have different clients for one monolith. You'll probably have different queries that are tailored to different clients that are consuming your GraphQL or REST API. So it's basically monoliths, one API to rule them all, which is perfectly fine because most companies don't even get at a size that they need to have microservices, but if you get there, then microservices is also something that's very interesting for API developers. But for front-end developers or React developers, it will lead to some extra difficulties, because I always like this meme about microservices. So when your boss tells you we're converting to microservices, this actually can happen. So microservices are tiny services, that's why micro, and it's one service for a separate goal. So maybe you have one service for your authentication, you have one service to get your users, one service to get maybe information about products, another service to get for your check-out orders, all these things will be divided into different microservices. And these microservices of course need to be unified somewhere, maybe an API gateway, maybe your front-end is calling all the microservices separately, which is something you should try to avoid. So even if you're not using back-end for front-ends, it can be an interesting outcome for this talk, learn about how you can use Next.js in order to have one unified gateway for all your microservices.

So what are back-end for front-ends good for? So we now sort of know why we have back-end for front-ends, so we had monolith APIs, which is nice, but can be confusing if you have multiple clients using the same monolith. We already also saw microservices, which are also perfectly fine, but it can also be very confusing if you don't have an API gateway in place or the division about who's responsible for what microservices very, very strange.

It could also be, depending on your company. So what are back-end for front-ends good for? So I already saw this picture, so you could have a set of microservices, or it could also be a monolith. That's something I also see happening.

So people have a back-end for front-end that's connected to the monolith. And from the monolith, they just have separate REST APIs that they're using and APIs that they aren't using. But it's back-end for front-ends, or back-end for mobile ends, I like to call them, it's just called mobile client and back-end for front-end as well. So we have a back-end front-end for a web client, we have one for a mobile client. And the reason that these back-end front-ends are there is probably because you have very different experiences.

So maybe you have a web client that is a huge dashboard interface while your mobile client is just a very simple version of that. So for that use case, back-end for front-ends are great because you actually can separate concerns, you can make sure you don't have any interactions between different clients. And also if one thing breaks, the other thing doesn't necessarily also breaks unless of course one of your underlying microservices or monolith breaks. So a very different experience is one way to have a one reason to have a back-end for front-end. And also like I said the separation of concerns.

So maybe you're doing very different things in your mobile client and you don't want to have your web client be aware of these changes. So then the separation of concerns for this is perfect because maybe you also have more separations of concerns with even your services. So maybe your microservices or part of your monoliths are specifically tailored to mobile, then it can be a good use case to have this back-end for front-end better. And then the one I like the most is actually autonomy. So if you have a large scale company or maybe even a smaller company with one guy or girl doing the web client, another person doing the mobile client, and then one person doing back-end, for this autonomy already works because the back-end people don't have to worry about how the front-end consumes the product. While the web person can make one BFF for their web client that's specifically used by the web client, and he or she is the only person to actually use this. And the same goes for the mobile. So maybe you have one person doing mobile, they can build their own BFF, they don't have to worry about breaking anything in a web client. So autonomy is a really good reason to start using back-end BFFs.

But more services also has a downside of course and this is something I want to talk about today. So having more services always have a downside because if we go back to this an example, so you have the autonomy part but you have the services that need to be deployed, you have a BFF that needs to be deployed, and you have a web client that needs to be deployed. So if you're working on a web client you have three things that are important for you that need to be deployed in order to have your service working. So this is something to worry about because you have 1, 2, 3 services and then the mobile person also has three services and then there is already people working together maybe on their microservices on the back because maybe the web person is already helping out with the back-end person, then the other thing goes around and it's for just the startup. So if you're a big company you maybe have multiple teams working on a web client, multiple teams working with the back-end for front-end and multiple teams working on your microservices. So this is something to worry about because extra services also mean extra work. So this downside is for maintaining, for deploying, but also for innovation because if you want to make changes somewhere you need to talk with this whole chain of people in order to make sure you can actually make the changes you want to make. So NextJS API routes make this actually very simple, so I think they started this not so long ago.

So with API routes you can actually create, well the words actually say it, you can create API routes from NextJS. So NextJS is the internal routing system based on the files so maybe you have pages slash welcome, then you would have actually a slash welcome page in your website which people can go to in order to see a welcome message.

For the API it's the same, you can just have pages slash API slash welcome and then you have an API to get maybe a blop of JSON that you want to display on the welcome API page. So NextJS API routes they make this very simple and before we actually go under the hood why API routes are good, let's show what it will do to our architecture.

So before we had one backend for the web that was used by our web client and then we had a separate one for the mobile and then the mobile client using it and of course all the services but now actually for the frontend developers or the web developers it becomes already becomes so much easier because now they love just one single BFF that's built inside the NextJS app that they can do all the things for. So they don't have to worry about deployment, they don't have to worry about DNS, they don't have to worry about maybe where things live within a Kubernetes infrastructure, so it makes things for a web client way easier.

But also the mobile BFF of course could be able to use this BFF as well, so maybe if you don't have a separate BFF for web or mobile it can be a nice solution that may be even like I said before if you're now calling all your microservices directly from your web client without a BFF, the BFF can still be there in place in order to help you to do this more efficiently because then always you have a very nice way of seeing where things pull together, you have one way to actually normalize, to clean your data. So NextJS is very good with this, especially with API routes in order to build a BFF for your web app and of course then we would still have the separations of concerns, because if you are planning to have multiple BFFs or multiple backend for frontends, then you still separation of concerns because the web people are responsible for what happens in a web BFF and the mobile people don't have to worry about it, as long as they're not building their mobile application with NextJS of course, which is indeed possible with React Native, but it's a whole different discussion.

And we also have autonomy still. So we still have autonomy there, because the web people still are responsible for what's going on in an NextJS app, they're responsible for what's going on there in terms of data normalization, data cleaning, in terms of what APIs will be called, so everything will be done from just one single Next app, making it somewhat of a framework that's more full stack than we saw before. So full stack frameworks are becoming more popular in the React ecosystem, so we have like a Remix, or BlitzJS, maybe even Redroot for Node.js. So things are becoming more and more autonomous in terms of full stack considerations for React apps. And NextJS is also following this with the API routes. And most of all, what I see is the most important thing is you don't have the additional overhead of deployments, of making sure things are out there, or making sure things are up, having DNS, being responsible for other services, needs to apply to changes in other services, need to align maybe what's going on in terms of deployment at your web client, your mobile client and all the other BF steps out there. So the additional overhead really is gone when you start using API routes. And there are way more benefits, which I could show you in a bit, but most of all for me having all your deployments going on in one single directory or maybe one single repository is a huge accomplishment. So it will make Next.js way more approachable for people that are doing things full stack and maybe now have something running with Express. So let's check it out. So let's see what this looks like. So let me switch to my code here.

So there are multiple ways to use this pattern with the API routes. And before we actually go into back-end for front-ends, let's go to something like this. It's actually somewhat a back-end for front-end. So I've made an implementation with SendGrid. It's a way to send emails around. And what I did over here, actually one problem I have, I was using SendGrid directly for my client. And one downside you have, if you start interacting with third party APIs from your client or maybe you own microservices from the client, you can actually leak information. So if you look here, I have an API key, I have a list ID, and now I'm sending this from a backend API route, it will be handled in the backend. So the user won't see that there is a network request going on to SendGrid. The user will only see there is a network request going to API slash sign-up newsletter. So this is a great way to actually also hide underlying information about maybe your credentials, about your microservices architecture, about what service is responsible for what. So by doing it like this, it's one of the examples of having a BFF, is being able to hide underlying architectural patterns or credentials to a user. So if I would be doing this from the client, my user could actually see I'm making a request to SendGrid, so already giving away which third party I'm using for emails. Then I'm also giving away my SendGrid API key, and even my list ID. So I probably doing this from a client, it wouldn't be that smart. Not really to say stupid, but let's say it's not really smart, because you're leaking all this information to a user, and the user would be able to see this.

But what you also don't want to do, if you're just building a front-end, you don't want to build an entire API in order to do this. So previously, I either had to ask my back-end developer, hey, can you make an API call in which I can send something to a third-party API, and that probably will work out, but I need to be reliant on a different team. If I already have my back-end for front-end, I can probably make the change there, or maybe can ask a back-end developer there to make the change, but I'm still reliant on a different service.

So with API routes, I can do all these things just from one single code base. So you would create a page, slash API, slash send a newsletter, and it's the way you can actually hide all the things that are going on here for my user. So you're not giving away your third-party API, you're not giving away your microservice architecture or pattern. And also, which is the most important one, you're not leaking any sensitive data, because that's something you don't want to do. I'm going to assume most of our users are quite friendly, but maybe if you find an actual hacker on your website, then it's something you specifically don't want to do.

So another cool use case, which I also write down here, you can even use GraphQL. So this is one of the biggest upside I see here, using this together with GraphQL. And this is a really cool use case, specifically because GraphQL makes things way simpler for most of us, because we can have one API route that is a GraphQL API route, because GraphQL is a single API. And from there we can do all our back and forth things, all our cleaning, all the data normalization, make sure all our patterns are there. So it really helps us making things more straightforward. So let's go back to the code and see what it looks like.

So we have our GraphQL endpoints. So we just create an endpoint, pages slash API slash GraphQL. And here, define a schema. Uh, you define your resolvers and your resolvers will probably be just API calls to somewhere. So this would probably be, um, return call microservice, microservice X. So you know the drill. You're probably creating resolvers. You're saying which microservices you need to call, and then you actually create your schema. You're actually going to create an executable schema. And before I go to this, let's go here. So what I'm doing here, uh, I'm creating my executable schema, but what I'm also do I'm running middleware, which is actually a really nice future because, uh, the way they created API routes to make sure they are compatible with middleware, uh, to connect different services. So like we actually know from express. So I can now use Express GraphQL and basically every other middleware for express for my API route. So there's no actual need to turn up to spin up an express server. You can actually do all these things directly from, um, 1API route index s. So it's going to save you huge amounts of time of deployment, of making sure there's a docker, making sure there's all these other things and not saying even better host them because the API writes, you can also bring them serverless, which is really nice.

Um, I really nice way of doing this because by having it serverless, you don't have to worry about these things like deployment being available, being up. And of course, next year has been built by versa. It's also a support for that. And there's also cool new tools. If you want to make sure that your serverless, uh, apps and API is actually running, uh, but those maybe we can save them for the Q and a.

So there's running middleware. It's a really cool thing because, uh, by having this executable way of extending your API routes, it also makes it really future proof because all the things that have already been built all the open source libraries, uh, for different express API APIs. You can already do them now from API routes. So using this, I can just basically create a graphical API that runs on an API route. Uh, have all my resolvers have my schema there. We're in the middle there like express graphical, but maybe auto middleware for authentication middleware for logging, all just from one, uh, one directory. So it's a really cool, uh, cool feature to have.

So yeah, so if you want to learn more about using API routes and next AS, uh, of course, I need you to check out the documentation because the documentation really helped you try and understand the API routes, but besides that, I'm also launching a course about using next ES, but graphical well in API routes. So if you are interested in this course, make sure to go to my website, so it's hack team.io slash courses. And you could find a link to the building the serverless graph, well, API next is in this course. I will show, of course, more in depth, the code we already saw before. Um, and also learn some cool new tricks about API routes next years, most of all, also graphical. So we'll be building cool things, um, like network polling on the backend, uh, but also how to handle these API right. So next next to yes. Um, and most of all, also learn how to deploy them serverless. So if you do want to learn more about next to yes, make sure to go to next to yes. Website's fit to know more about my courses. Please go to my website. Uh, most of all, if you want to learn more about, uh, react graphical, TypeScript, uh, these kinds of things, make sure to follow me on Twitter or find my, um, find my videos on YouTube. Uh, and then I wish you really enjoyed the conference so far, and you still enjoyed the conference, uh, talks coming up. Because if I looked at the schedule, I see there's some really nice people talking about really cool, really cool things. So make sure to, uh, to stick around. And then I hope to see your questions flowing in on Twitter, uh, or maybe some other way you can find me.