Backends for Frontends

[00:00:00]
>> Steve Kinney: Another one that I hear a lot and use, and this is one of the ones where there are slides, but it is kind of what you think it is, and it's tricky because this one is either tricky or really not tricky depending on how you think about it, right? The concept of a back end for a front-end is that instead of hoping the back end team makes an API that you can use, you put an abstraction over the API that they gave you and make it so that it is doing what you need for the front.

[00:00:47]
I think I told you when I worked at Sered, it was something more than 10, less than 17, it might have been 12, it might have been 16, I forget the number, request just to put together the full user model, right? Would've been great, you know, like one option was, you know, then I was like, we should use GraphQL. Great, now you have another, like, everything you add to your architecture is something that can break, right?

[00:01:13]
And so the counterargument, because when I was on the architecture team, my job was to say no to everything, right, because every new thing was a thing that could break. And so our job was to say no constantly and have the burden of proof on why we should do the thing. But the concept of back end for front end is you can abstract over an API to give yourself one that you need that works better for the UI that you're trying to render, right?

[00:01:43]
And because I didn't always have enough empathy for the situation, which is, you know, a lot of times when you go to work at a company that has existed, you may or may not inherit what I would call garbage APIs, right, which is just like, what is this, right, and when I worked at Temporal and we were building a lot of the cloud SaaS because there's an open source project, but managing users and all that kind of stuff is the cloud shell that lives around that.

[00:02:15]
I was working with a bunch of really, really smart distributed systems engineers, the best practices for distributed microservices talking to each other and the APIs that you would build for that, and the best practices for building a UI are fundamentally different, right? Like, it is a best practice. I'm like Go engineers, it is not a best practice you were lied to, possibly. To them, it was the best practice of like, well, for the list, I will just send you an array of IDs and then you can go hit the individual requests to for each one so you can build the UI to show all of the different, you know, name, units of whatever you're building.

[00:03:02]
And I was like, so I'm going to make one request, get a bunch of IDs, I'm going to fan out, make 43 more requests in the browser. Absolutely not. Just give me a slimmed down version of what I need for this view. Right? And for them who are worrying about API surface layer and support, they're like, absolutely not. Right, which is a fascinating, like they're not necessarily wrong. I mean, I thought they were wrong, but they're not objectively wrong, it's just inconvenient for me, right?

[00:03:33]
And so that's where kind of this pattern come in where you wrap, because for instance, if you just decide to do that on edge, right, you could do it on a server, but I would argue if you care about performance, you know, Amazon has Lambda at Edge, many companies will then wrap that and sell it back to you, right? Vercel has edge functions, Cloudflare has edge functions, they have their own infrastructure and for sales across all the cloud providers, you know what I mean?

[00:04:03]
Like there are ways to do stuff at the CDN edge, where you sew all that together, cache it, and then compute it beforehand and then be able to serve it super fast to the UI, right? And it goes back to that team autonomy, you're not necessarily waiting for the back end to give you that API that you need for that UI because design insists that it has to show this, and the, you know, the hardest part of being a front-end engineer is I will see an amazing set of designs, and I will see a reasonable set of APIs, and then I will have to tell both of them that this can't happen, you know what I mean?

[00:04:34]
Like you can't, this UI with these APIs is not going to happen. One of you has to budge. The answer is usually no, and then you write a knot of client-side code to somehow try to appease everyone, and that becomes your tech debt that you live with forever. But, you know, and so the idea is that you could at least give yourselves those abstractions. Now, I will tell you, having done this for a very long time now, politics is a thing.

[00:05:08]
Right, like, you know, the people, the principal engineers on the back end team are going to have a lot of feels about the front-end team managing back end services, or, you know, security usually has got some things and also the front-end team doesn't want, like front-end on call is a joke compared to backend on call. I used to be a manager on call. I'm aware of what the backend teams have to go through.

[00:05:34]
So sometimes the reason you want to do it is like, then you have to be on the hook for a thing that can go down, right? Like there's very few front-end outages. The S3 bucket got deleted. But it is worth considering, right? Like, but again, it is yet another node of complexity. It's another thing that can go down, it's something you have to manage and depending on, I think that if you think about something like SvelteKit or Next, where you're putting those server load functions right next to JSX, what do you think you're doing?

[00:06:12]
You know, like you're doing this, like the bottleneck to the sheer number of calls that you need to make is the problematic piece, then it's worth, can I consolidate these into one, right? And that's true with the module federation, like those are all jumps over the network. There's caching and all of those things, but they're also things to consider and measure. And worth to consider. A lot of, when you look up back ends for front ends, there's a lot, you'll see a lot of diagrams of the web needs one set of APIs and the iOS app needs another.

[00:06:46]
That could be true or not. I've personally never experienced that being the real need, right? And I don't know that you need a back end that covers every API, but I think it is worth considering the places where it hurts, and that's this portion of the architecture appendix before we get into keeping everything alive is about this set of things where maybe they're not always and with the monoliths, micro front ends, monorepo, no matter what you've chosen something, maybe a weird hybrid of them, but these don't, they're kind of opt in.

[00:07:18]
The rest of them you're, you have either one repo or you have more than one repo, right? Like it is either built all in one asset or it's not built all as one asset, right? Like those are, you have to make a choice because no matter what you have made a choice. These are kind of more opt-in pieces as well. You know, obviously, if you wanted to do this on a monolith, everything is easier, right? Because how many apps need to talk to this back end and the front-end, right?

[00:07:48]
If you have many autonomous teams in a micro front end architecture, who owns the back end for the front-end? You want to make a change, how many teams are you going to talk to? We'll talk about some of these things tomorrow in the keeping your codebase alive piece, but they're worth thinking about and every decision has trade-offs with another decision.