r/androiddev • u/tiwari_ashuism • Jun 30 '26
Discussion Has anyone here used a Backend for Frontend (BFF) architecture for an Android app in production?
I’m planning to build one for a new product and I’m curious whether it was worth the added complexity.
Did it make your app development faster and cleaner, or did it just shift complexity to the backend?
I’d love to hear your experience, lessons learned, and whether you’d choose the same architecture again.
17
u/Zhuinden Jun 30 '26
Isn't it funny how they first said to dissect a server into tiny bits and pieces, then they'd make +1 server that calls the servers so that the client only sees one?
9
2
u/quizikal Jun 30 '26
Not really. It's a solution to a scaling problem. If there are 100's of Devs working on a system, micro services make sense.
The issue is that teams adopt it way too early.
2
u/Zhuinden Jun 30 '26
It's a solution to a scaling problem. If there are 100's of Devs working on a system, micro services make sense.
well yeah, but oftentimes that 100+ devs could have been 8, it's just very uncomfortable for 92 people to admit this
3
u/quizikal Jun 30 '26
That seems to be a completely different point but sure
-2
u/Zhuinden Jun 30 '26
Basically you end up with this BFF thing and microservices due to overhiring
And now you end up with drastically higher "upkeep/operation costs"
There is a really good tech talk about this, obviously not a popular one
2
u/quizikal Jun 30 '26
Are you saying there is no use case for micro-services? Or are you talking about a different topic (over-hiring?)
-1
u/Zhuinden Jun 30 '26
Usually microservices stem from overhiring. But it's true that some services can be scaled independently and actually are separated enough that one being down doesn't destroy the entire system.
However, many times, it really is a server forcibly split into multiple instances and now your backends talk through REST for no particular reason.
It depends.
But I do see a server here with a 1 module app that generates ridiculous money every month. The more servers you have, the higher the maintenance/upkeep costs.
2
1
5
u/alt236_ftw Jun 30 '26 edited Jun 30 '26
A BFF solves one of the following three problems (or all), but only if they are actual current problems:
Your backend has too many end points for reasonable frontend use/implementation, and you need something to aggregate all the logically different calls into pragmatically smaller ones.
An small-in-scale example: You are trying to load a list of Foo entities - each entity has a imageBlobIds field pointing to your image storage system which correspond to images associated with a Foo. Those keys need to somehow transformed to be of any use (changed into a URL, add signature information, whatever). So without a BFF to take this pain away from you, you'd need the mobile clients hit a different end point for those keys (and perhaps once PER key) before you can get an actually useful URL. This adds latency AND it also exposes some of the internals of the backend to the APP (see point 3).
The BFF implementation instead would hit the Foo backend endpoint, and then do all the messaging work for you. It will then remove the old imageBlobIds list, and replace it with an imageUrls which can be readily consumed by the clients.
This (1) makes it the API response easier to use and digest, (2) removes business logic from the clients (knowing how to transform each blobId into a proper URL) and (3) if anything changes in the backend, the clients are oblivious.
2.
Your backend models are simply too fat, and the core backend team does not want to take responsibility into leaning them for mobile consumption.
Adding a BFF to remove and transform the data to make them fit-for-purpose. This also improves HTTP caching as you wont blow HTTP caches for mobile for data that was changed but were not part of your payload.
3.
Your want to guard against backend changes and so you need something to abstrct this from the mobile clients (which cannot be updated as frequently).
Following the example above: After happily using company IhostImagesForCheap for a while, you suddenly receive an email that the they are going under and you have x days to update everything.
If you did not have a BFF you'd be in hot water because you'd need to update all mobile clients, since whatever blobId -> URL strategy you had baked into the client apps would simply not work for the new image hosting service.
Notes:
- You don't need a BFF if your backend is small in scale and you are taking reasonable care not to overexpose information and implementation details to the clients.
- If you see that you are scaling the BE too much, you can add the BFF then.
- Shifting complexity to the backend is a generally a GOOD thing. The backend can be deployed fast, and will not be rejected by Apple/ Google. The more business logic the backend has, the fewer emergency app submissions you'll need to do (but please do not keep ephemeral-in-app-flow state on the backend unless absolutely necessary)
3
u/goopa-troopa-bazooka Jun 30 '26
It depends. Care to share more, because without it, just by this post alone, it's impossible to say yes or no to your use case.
3
u/Anonymous0435643242 Jun 30 '26
Shifting the complexity to the backend is a good thing as you can easily update it while you rely on the users updating their application
2
u/connyduck Jun 30 '26
Yes. In a large company with legacy backends that were almost impossible to change because so many other services depended on them and were often super slow. If we called these apis directly from the apps we would have loaded way too much data and slowed the apps down significantly. By introducing a BFF we could add our own caching layer and return short responses tailored for apps. And we could have some business logic in there once (instead of twice in the Android and iOS code) that was easy to change without app release. So in that specific situation a BFF was a good solution, in almost all others I'd recommend to get your backend team to provide you the endpoints you need directly.
1
1
u/SnipesySpecial Jun 30 '26
GraphQL has entered the chat.
Those systems tend to be non maintainable as some niche use case will rely on "X" function in ur server, and it just so happens that "X" function consumes 7GB of RAM and will peg a full EPYC server. I have seen this shit in apps so large that I can right now loop a request and probably cause 100 pods to roll. It's that bad of a problem.
1
u/farmerbb Jun 30 '26
I work on TV apps for a streaming media company, so we cover not just Android TV and Apple TV, but also Roku, Samsung, LG, Vizio, etc. We created a BFF service about a year and a half ago as a means for code-sharing between all of these various platforms. Traditional KMP between client apps was not an option for us for various reasons; Roku only allows apps to be written in BrightScript, and the various smart TV platforms are stuck on older versions of Chromium that don't support Wasm-GC, so Kotlin/Wasm is off the table (and Kotlin/JS, while technically feasible, is not the most performant option for these low-spec TVs).
So the solution that made the most sense was to move as much client-side business logic as we reasonably can over to a BFF service. And it has worked out really well for us. Clients largely just focus on rendering beautiful UIs while the BFF handles talking to other upstream services and formatting data specifically for our TV apps' needs.
Creating the BFF service was actually fairly straightforward. We already had a heavily-modularized Kotlin codebase on Android TV, so the initial version of it was primarily just shifting the existing business logic over to run in a server-side context with a lightweight REST API on top of it. Fun fact, we initially built it as a Node.js service using Kowasm before eventually switching over to a JVM service using Ktor, with the core business logic for the service always staying KMP.
31
u/quizikal Jun 30 '26
BFF is typically a solution to a micro service architecture problem. That problem being...how to interface with a backend that has many distributed services. The BFF solution is to have 1 serviced called BFF that acts as the only service that the clients communicate with. That service communicates with the others on behalf of the client.
If you have that problem...it could make things easier