I use react as rendering library. And I use Django on the backend. But I don’t like that frontend applications get very fat and there is an ever existing tension between building a general API and the frontend driving the features.

This lead me thinking about Backends for Frontends as possible solution. Move from react to NextJS, define the backends for frontends in NextJS and the services in Django.

I don’t like the idea of writing Typescript backend code, but this is not really the case. It only assembles and orchestrates services implemented in python. Bigger views in SPAs do effectively the same in the frontend, which is even worse. Using a TS-Backend at least builds a nice context per view and keeps the frontend simpler - and enables file base routing (great for code navigation) and server side rendering.

The layer of indirection means that I can focus on high quality APIs on the Django-side and the frontend can drive the backends for frontends. It also gives the added benefits, that I get another channel of distribution for my services. If I have a machine-learning inference service, I can just wrap it in fast-api and deploy it as docker-container using it via the TS-layer.

I don’t like the idea of indirection as it may make things harder and more complex, but in this case the backends for frontends are coupled completely to the frontend, so this may not be an issue. I will give it a shot and see when I got some experience.

A note on technology choice: I guess the best backends for frontends technology makes it transparent what is running on the frontend or backend. There are a view candidates out there like NextJS, Closure web frameork, Phoenix and so on. Seamless integration, DX and Debugability are keys.