48 ms·
Originally this was a Netflix pattern I believe, and the key trade-off there is that there are lots of client implementations/versions and they are hard or impo
by theptip 4y ago
Originally this was a Netflix pattern I believe, and the key trade-off there is that there are lots of client implementations/versions and they are hard or impossible to upgrade (eg set top boxes).
And typically you want to call a few different backend services in a given API call, with perhaps different trade-offs; one device might need cover photos up front, another might just do text summaries, to take a made-up example.
If you have one API gateway then your clients tend to be thicker as they need to figure out how to weave the different API calls together. And/or your API gateway gets clogged up with lots of usecase-specific variants.
So if you extract a per-frontend(-family) backend you can keep more of the logic in your backend system where it’s amenable to change as the upstream services evolve, and keep the device logic better modularized.
If you just have iPhone vs Android apps it may well be cheaper to just eat the complexity cost of having different APIs on your single gateway, to avoid having to pay the cost to deploy multiple bff services.
- echelon 4y ago> cost to deploy multiple bff services Pennies on the dollar. And now you have a concrete view into exactly what Roku App v3 needs. And with this pattern you can migrate with marginal blast radius, unlocking developer centuries of productivity. Cross my heart and hope to die.