If you actually measure real latencies (e.g. collect metrics from your mobile apps), this is not true most of the time, at least in my experience. Most responses are fairly small, making them a bit smaller doesn’t have much impact on mobile app performance in the real world.

I’d guess for most apps, there are maybe a handful of endpoints where the response size can be reduced a tonne for mobile clients, AND that makes a big performance difference in practice. But instead of hopping straight to BFFs, or other approaches to solving this like GraphQL, you can just add a “fields” query param to those few key endpoints. If provided by the caller, you return only the fields they ask for. No massive re-architecture to BFFs or GQL, just a small change to a couple endpoints that a single dev can implement in a day or two.

Now, there are other benefits to BFFs than minimal, client specific payloads. One is that you can make breaking changes to underlying APIs, and not break always-so-slow-to-upgrade mobile clients, by preserving backwards compatibility in your mobile BFF layer. Another is coordinating multiple calls - turning many sequential round trips into a single round trip can be a big win. But if your main concern is payload size, BFFs are probably an over engineered solution.

Dylan Beattie actually talked about resource expansion (with HAL) about 6 years ago: https://youtu.be/g8E1B7rTZBI?t=1654

Essentially, it was a really nice and concise explanation of links to other data, problems with those and adding resource expansion to API endpoints.

That said, it feels like HAL never really took off and the implementation of something like that is very framework specific.

> ...or other approaches to solving this like GraphQL...

GraphQL does seem to solve this, but it's like someone made an equivalent to SQL just for APIs, except that they forgot to include the bit that actually talks to your data store based on the queries and returns data, so you have to write that yourself (e.g. query resolvers).

Unless you're using something like PostGraphile/Prisma/Hasura which exposes your database (provided you use one, which might be the situation in most cases) through GraphQL, but then you run into problems with intermediate data processing or additional access controls, that you might need to be API logic, before your data is returned.

So, instead of the old approach:

  [client] <-RESTful request-> [your API] <-SQL query (with parameters)-> [SQL database]

  [client] <-dynamic GraphQL query-> [GraphQL intermediate solution] <-SQL query (with parameters)-> [SQL database]

  [client] <-dynamic GraphQL query-> [your API] <-dynamic GraphQL query-> [GraphQL intermediate solution] <-SQL query (with parameters)-> [SQL database]

Back to the topic, BFFs seem like a good idea, especially if they take over some of the gateway functionality as well. I've heard them be described as facade APIs in some cases.

Agreed on increased complexity, but isn't the point largely the dynamic queries? You setup all this extra architecture, but in response you don't have to write as many "controllers" with custom API response. Just let the frontend request what it needs via GraphQL. So it's more upfront work, less down the line. Or is writing all the API level sanitizers and query resolvers more work?

What about cases like: "The user should only be able to see the data of their own submitted requests, when the parent document is any of the given statuses: FOO and BAR and there is no related BAZ request that's been saved and is approved in the system by the manager. In cases, where the BAR request exists, ..." (a long list of other edge cases that might affect the visibility of any particular document or even individual fields in some form)

My point is that in many systems the cases where you might want to just give someone the ability to retrieve the data they need is rather limited. So in those cases the dynamic nature of everything is more of a risk than anything else.

There’s also caching, which is another side of the same coin as indexing. You may want to cache certain common/expensive queries. You’ll probably need to think about the granularity of what gets cached, and how to invalidate it. Hard problems for a dynamic, “query anything” API.

Also you probably need to control which data can be retrieved. KronisLV covered that.

The old approach has been more like this:

  [client] <- RESTful request -> [your API] <- Your data fetching logic -> [DB] <- SQL query (with parameters) -> [DB]

If anything, I'd prefer to go the other way and get rid of SQL altogether - let me express queries in code:

  books.filter(book => book.author === "Alice")
       .group(book => book.year)
       .map(group => group.reduce(({ sum = 0 }, { year, sales }) => ({ year: year, sales: sum + sales }), {}))
       .sort((a, b) => b.year - a.year)

  SELECT year, SUM(sales) FROM books WHERE author = 'Alice' GROUP BY year ORDER BY year DESC

Which stands to reason given that GraphQL was designed for talking to services, not data stores. It was built for BFF. The backend is responsible for talking to the data store, as usual.

[client] <-dynamic GraphQL query-> [GraphQL resolver] <-boring old RPC/REST/whatever-> {Set of backend services}

It would technically be faster because of lower latency between services in the same data center and sending the final results to the user in one go, but at the same time if your DB is hit 50 times to service that request, you still have a problem.

Essentially you just give the client the ability to run dynamic queries (with the complexity of which, the resolvers and their logic, you now need to deal with), without actually improving anything else, at the cost of noticeably increased complexity and yet another abstraction layer.

That tradeoff seems like a tough sell to me, much like an SQL engine that's not tightly coupled with a solution to actually store/retrieve the data would be like. Then again, there are solutions out there that attempt to do something like that already, so who knows.

Which is a pretty big deal when you have practically the whole planet as users, many of whom are found where low latency is a luxury.

> but at the same time if your DB is hit 50 times to service that request, you still have a problem.

Maybe. Or when you are Facebook maybe you don't care. Just throw another datacenter at the problem.

> without actually improving anything else

They found it improved discoverability for designers and non-technical folk.

> That tradeoff seems like a tough sell to me

If your organization doesn't look like Facebook, I imagine it wouldn't sell. It's very much designed for a purpose.

This is an excellent point!

Different scales will need vastly different approaches and the concerns will also differ. Like the anecdotes about a "Google scale problem", where serving a few GB of data won't phase anyone, whereas some companies out there don't even have their prod DBs be that size.

If you are a small team of developers that is no doubt a lot of unnecessary indirection. When you are small you can talk to each other and figure out how to create a service that returns the optimized results right away. At Facebook scale, if everyone tried to talk to each other there would be no time left in the day for anything else.

Conway's Law strikes again.

I'm now at a point where I'm not sure what the next step should be. I believe caching may be the next logical step, but I've been hesitant due to concerns about the staleness problem, knowing when to bust the cache, etc.

And then even if we do go the caching route, I'm unsure at what level we want to cache. Do we cache individual objects or do we cache the large, fully hydrated models (the ones that require many queries to assemble)? Then there's the problem of having to mix and match fetching objects from the cache in the context of other arbitrary DB queries that can be constructed.

How do people generally go about introducing caching? Do you try to limit the scope of caching as much as possible (like to the lowest/smallest objects) and see whether that's sufficient to get the performance you want and then increase the caching surface area from there?

Also, what approaches do people take from the technical side? We already use Redis for some things so I implemented a quick proof-of-concept that seemed to work in the small scale. I've also seen people use Elasticsearch to keep fully hydrated/rich models in there and then use ES as the read store. Are there merits to this approach? Crazy?

Really keen to hear anyone's thoughts or guidance on this!

An API is designed to aggregate and format data from various data-sources. The speed of your REST API will ultimately come down to the SQL queries that need to be executed and how your RDBMS executes them. Using a naive ORM (such as Django or GraphQL) typically leads to poor performance as you lack control over query execution.

Have you written your SQL from scratch and benchmarked slow JOINs? Sometimes doing multiple queries is faster than JOINs (when you only need to fetch related data for a small number of entities for example).

Are you using covering indices to accelerate entity lookups? This is probably the main way of speeding up your DB. De-normalizing your schema in certain cases is also a hack to be aware of.

Have you tuned caching in your RDBMS? You don't really need Redis when RDBMS can do caching for you (hint in-memory tables are awesome, RAM is cheaper than dev time).

Have you tried stored procedures? If you have complicated queries this may be helpful.

There's a whole list of things you can do to get great performance out of your RDBMS. Start there instead of introducing another layer of abstraction/tech that will complicate the architecture. I can guarantee that good schema & query design can yield massive improvements.

Stored procedures is not something I've tried yet, but will look into it. Any more color or examples how this might work in an application?

Are far as RDBMS caching goes, you're referring to the ordinary query caching, related to things like shared buffers in PG, etc?

Just want to make sure I'm clear on all the suggestions you raised. Thank you!

Avoid ORMs, GraphQL etc - write raw SQL specific to the views that your clients need, if you care about performance.

Low hanging fruit is:

- connection pool: your DB can in all probability execute many simple PK lookups at once, make sure you've got a large enough pool of DB connections to let it do this

- covering indices: if you are computing over columns A,B,C but looking up by PK you can add a covering index over (PK,A,B,C) which means no disk lookups. make sure all queries are using an index!

- joins: ORMs generally don't know how to do joins and use multiple queries instead. You need to get the right balance, for example for HN it could be: get PKs for top 30 articles in one query (one covering index), and lookup their attributes in another query (using a join across N tables where PK IN (1,2,3) which doesn't use a covering index). Reason being: covering indices are expensive, so you minimise the data they hold by splitting up your queries.

- de-normalization: if you have very complex joins, de-normalizing your schema may help

I wouldn't worry about stored procedures to begin with, unless you have a very complex schema/query plan. For caching you just need to make sure you have allocated enough RAM for your DB to keep indices in memory, the more you allocate the more pages it can cache in RAM. Focus on schema + SQL.

Prisma could handle the query generation part somewhat intelligently, at least in the future.

Denormalization is not a low hanging fruit. It may seem so because the mass of all the tangled fruits makes the top branch droop down where it can be munched on, but never quite satisfactorily picked.

Sure it means you don't have to learn SQL at all, and that's really the only advantage. But time spent learning an API/ORM is better spent learning SQL.

Storing code in a database is a terrible idea unless the entire workflow can support developing, debugging, deploying and monitoring that code.

If you absolutely cannot do that, cache at entity resolution level. Although, it really doesn’t solve the actual problem, just makes it more bearable by offloading primary DB workload to another DB, so why not run a read replica instead?

With regards to using a read replica, we do have one that we use for some queries, but that doesn't really resolve the problem with having to do many queries for certain endpoints. We can only eliminate so many queries before the backend code becomes unmanageable, because we effectively forgo any of Django's ORM in favor of our own handcrafted queries that are hard to reuse.

Thank you!

Note that depending on your data model, you may not need ”complex” edges, just ”simple” links directly from vertex to vertex. Not all databases support this.

Then again, you already might have N:M tables which exactly correspond to edges in a graph model. This distinction is something to keep in mind.

>>> Tools to make migrations from Django (and other ORMs) are possible but we haven't yet started working on them. So you'd have to write the migration script manually.

Still don’t see the need for architecting hydras like BFFs

I've worked in a few orgs where backend devs work on both the standard backend and the BFF, often adjusting both when adding new features. It's just convenient to have a separate layer closer to the frontend, dedicated to it.

On the surface may sound weird but in practice has actually been pretty great when used mindfully.

Writing your BFF in the same codebase, sharing types, and parsing incoming data on the server without filling up the client bundle is a fab experience.

PS: I wouldn't call it "political" (negatively connotated) but "organizational" (statement of fact)

If you're arguing that most microservice vs monolith decisions represent a political and not a technical decision, I'll grant you that.

Your post brings up an interesting angle which is that the frontend and backend people can have different expectations of what the backend should actually do (perhaps leading to dependency spaghetti). In this case, introducing a BFF can be a way to isolate that from the rest of the architecture.

This is the degenerate form of Conways Law.

The BFF layer seems like a natural next step, basically a code shim to abstract away the peculiarities of each FE platform from the (presumably) "pure" business logic / API platform of the BE.

However, assuming you've got them, BFF means only one group has to get the following right:

* User authentication

* Web performance analytics

* A/B testing

* More difficult bits of HTTP (fast TLS, prefetch, streaming responses)

If you have microservices but no BFF, you're pretty much stuck with your page being substantially rendered via js. Maybe that's okay for some things? I sure don't like it.

if your app gets "bigger" this can work OK, but I've found they typically get "wider" and then any work on the monolith gets really painful and slow. My last two gigs have been at opposite ends of the spectrum and it's kind of a "pick your poison" situation.

In the case of GraphQL Federation, the ”BFF” does solve the N+1 queries problem, which is an actual problem.

Edit: Which I see you agree about.

If you force your frontend to only use what makes sense as a "general" backend API, it ends up being inefficient. There are 1:n calls needed to get all data, or a lack of a specific filter requires pulling back everything to do client side filtering, etc.

On the other hand, if you build out your back-end to support every single front-end use case, it gets massive quickly. If other third parties start using it (as part of your published API) you now are forced to support it long term - even if your frontend changes and no longer consumes it - until you finally decide to break backwards compatibility (and the third party app). Break things enough and your users will quickly hate you.

This is especially true early on, when your frontend is going though rapid and radical changes.

I see BFF as the intermediate, giving best of both. You can rapidly adapt to front-end needs but don't commit to long-term support. There's actually no need for BC support at all if you can deploy front-end and BFF atomically.

If you build your code in a structured way, you're sharing the actual business and data logic, and it's trivially easy to "promote" a BFF resource to the official API, with whatever BC commitment you want to provide. The key thing is you are doing this deliberately, and not because the front-end is trying something out that might completely change in the next iteration.

If you have a 3rd party using an endpoint, it kind of changes things. Providing short-term instead of long-term BC is maybe slightly less effort, but any BC at all is an order of magnitude more work than none.

With no BC, you would basically say "Hey on Thursday afternoon we're deploying a new version and the old one goes away -- be ready!". That nearly guarantees a 3rd party will have downtime, and is frankly a very hostile way to treat them. If I was the 3rd party I'd either be hounding your business for a long-term BC commitment for anything I use, or complaining about how it's a garbage API that constantly breaks on us and advocating switching away to a competitor ASAP.

Any half-decent backend API will offer parameters to limit the response of an endpoint, from basic pagination to filtering what info is returned per unit. What's the use of extra complexity of a "BFF" if those calls can be crafted on the fly.

And to be clear, I am not suggesting that custom endpoint be crafted for every call that gets made, that just seem like a strawman the article is positing; but rather that calls specify when info they need.

A mobile client may need data points to display a single page that require calling 20 different APIs. Even if every single backend offered options for filtering as efficiently as possible, you may still need an aggregation service to bundle those 20 calls up into a single (or small set) of service calls to save on round-trip time.

This pattern is advocating for reduced technical performance to accommodate organizational complexity, which I think the parent finds odd. You either have the client call 20 service/data?client_type=ios or you have the frontend backend call 20 different service/data?client_type=ios (after the client called)

> You either have the client call 20 service/data?client_type=ios or you have the frontend backend call 20 different service/data?client_type=ios

The article touches on this point, and it mirrors what I've seen as well. The time from client -> backend can be significant. For reasons completely outside of your control.

By using this pattern, you have 1 slow hop that's outside of your control followed by 20 hops that are in your control. You could decide to implement caching a certain way, batch API calls efficiently, etc.

You could do that on the frontend as well, but I've found it more complex in practice.

Also a note: I'm not really a BFF advocate or anything, just pointing out the network hops aren't equal. I did a spike on a BFF server implemented with GraphQL and it looked really promising.

I'd much rather issue 20 requests across a data center with sub-millisecond latency and pooled connections than try to make 20 requests from a spotty mobile network thats prone to all sorts of transmission loss and delays, even with multiplexing.

Tbh, I'm not entirely sold on this - although I see this (server-side aggregation a cross data sources) as the main idea behind graphql. So seems like it belongs in your graphql proxy (which can proxy graphql, rest, soap endpoints - maybe even databases).

But for the "somewhere" part - consider that your servers might be on a 10gbps interconnect (and on 1 to 10gbps interconnect to external servers) - while your client might be on a 10 Mbps link - over bigger distances (higher latency).

Aggregating on client could be much slower because of the round-trip being much slower.

In addition, you might be able to do some server-side caching of queries that are popular across clients.

The architecture really only makes sense if you have a lot of people that would step on each other’s toes if you don’t assign them their areas and would come to a halt if you didn’t gave them enough autonomy.

Having multiple layers of backend services can have benefits, and one of these layers would just happen to be dedicated to the public facing frontend. To me the one of the main advantage is to make it easier to manage the security settings and applying different assumptions across the whole API. It is single purpose, so it helps a lot for customization and management (or even choosing a different stack altogether, having different scaling strategies etc.)

It becomes something managed really differently when the "real" backend is opaque and off limits (as describe in the article), but then I'm not sure we should call that "BFF", it's just a regular backend for that team as they have no other backend in charge (i.e if I had a single backend API for a mobile app, that I use to interface with Stripe, I wouldn't call it "BFF", that would make no sense)

Each of these vendors needs a list of accounts in an area. Deep in the stack, the list of accounts and managing individuals tied to those accounts is one service. The vendor doesn't need access to the rest of the service, just the list of accounts.

Each vendor also needs to be able to submit orders and issue refunds. That's a different backend service.

One of the vendors has been known to be... shall we say "inconsiderate" in the rate of requests. It is important that the inconsiderate vendor doesn't impact the other one's performance.

We could add in basic auth into those back end services and add in some more roles for each one of the vendors. This would complicate the security libraries on the back end services needing to accept internal OAuth provider, external OAuth provider, and basic auth - and making sure that someone internal isn't using basic auth because they shouldn't be. And trying to handle per account/application rate limiting on those back end services that really don't need to or want to care about the assorted vendors that are out there.

So, we have a pair of BFFs. They're basically the same, though there's a different profile setting in Spring Boot to switch which set of auth is configured - if its the vendor that uses the external OAuth provider then the external OAuth configuration is used. If the profile is for the other vendor, then the basic auth is used.

Each BFF calls the appropriate internal services and aggregates them - so that the internal services don't need to be concerned with the vendors. There's a BFF that has two instances and has access to these endpoints - that's good enough for the internal services. Likewise, each BFF has its own rate limit so that the inconsiderate vendor won't overload the backend or accidentally rate limit the other vendor out of being able to make requests.

The BFF handles the concern of the vendor. Aggregating the internal requests, rate limiting that vendor, providing isolation between the two vendors, and each handling the authentication and authorization for the vendor. By putting those in the BFF, those aspects of making requests to the vendor are kept isolated.

Additionally, the API contract for the vendor can be held constant while internal teams can change the internal API calls without worrying about if that data is leaking out to the vendor accidentally. Services internal can be updated with new endpoints and the BFF can be changed to point to them as long as the external vendor API contract remains the same - without needing to involve the vendor with a migration from a V1 endpoint to a V2 endpoint.

It has been used to query the data model by some. Data is data at the end of the day. But that is not where it really shines and misses some of its advantages when the service layer is skipped.

But shouldn’t the individual services be protecting themselves?

That said, I think there’s a case for BFFs - even ones implemented in GQL - when there is a need to support devices or customers which you can change, and which may live longer than your API.

CRUD may be fast on the server side, but if the client is performing a complex workflow of CRUD calls, you're incurring the round-trip network cost each time. The more you can coalesce the workflow on the server side, the lower round-trip network costs you'll incur, which is the real bottleneck here (10ms server processing time vs a wild range of 10ms-1000+ms network latency, depending on where you are/what you're on).

Our company has been working on a new large platform built around BFF and it's been really nice to work with.

We have several SPA and mobile apps which interact with our data very differently. It took a bit to break the mindset of using the HTTP layer as the "point of reuse" but now it's far easier to add and maintain functionality.

We feel much more productive compared to past projects where we spent a lot of time trying to make "one API to rule them all" with a single ever-changing model.

Why isn't there just one API gateway with minimal front-end-specific endpoints?

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.

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.

If you have a single module that needs to support customised APIs for each front-end client, and each of those APIs potentially needs to talk to the now-internal APIs for each back-end service, you’re back to the monolith problem where everyone has to co-ordinate changes and deployments with everyone else. Chances are that you adopted microservices to avoid exactly that kind of problem.

If the modules in your new layer instead correspond 1:1 with your front-end clients but each might need to depend on multiple back-end services, you create new problems if the back-end teams have any responsibility for maintaining the new modules. Now each back-end team has to understand all of the different front-end clients using its service and cater to each of them separately, and you also need all of the relevant back-end teams to co-ordinate on any changes and deployments of each front-end client’s back-end API. Again, this is adding new responsibilities and overheads that you didn’t have before.

So that brings us to the idea in the article, where each front-end team is responsible for maintaining its own back-end API module as well. This avoids the original performance problem of having each front-end client making an inefficient set of relatively slow requests to multiple general-purpose APIs for different back-end services, but without needing any extra knowledge or co-ordination between teams that you didn’t already need anyway.

This is what the vast majority of developers are facing. Be thankful, if you don't have to clean these messes up only to move to another team to repeat it. It happens naturally because of the tension between shipping things and finding enough time to properly optimize.

Consider an app that has a TV interface, a desktop interface, and a phone interface. The UI might be very different on each. You might want different art at different sizes/aspect ratios for different interfaces (consider different ways of browsing content on a streaming media service, including potentially "live TV guide" views and/or series-vs-show-level navigation). You might iterate on those interfaces at different rates - it's easier to release to the web than to mobile, and it's a LOT easier to release there than to, say, Samsung TVs.

So either distinct sets of APIs for each, or some sort of graphql-style "get just what you ask for" open-ended API contract becomes necessary.

The former is often easier to optimize for performance if you don't truly need unlimited permutations, but just a handful of them.

Nothing here is impossible to do out of a single API gateway, but you're likely run into some problems over time:

* at a certain number of people, a single team working in a single codebase often steps on each other's feet more than is productive

* at a certain feature complexity, the API gateway becomes much more "custom logic for each device" than "shared aggregation of stuff from individual backends"

* at a certain company/product organization/roadmap size, trying to sequence and deliver priorities for three competing client teams at the same time becomes tricky

Splitting up the teams to each focus on different clients lets you accomplish organizational resource splitting at a higher level (how much do we staff these teams) than stakeholders having to jockey for prioritization on every single feature.

Once the teams are split up, splitting up the codebases and deployables makes sense too - if you're responsible for the mobile API, you don't want to be paged because the TV team pushed something that screwed up your crap, etc. You can do finer-grained optimizations at that point, too.

1. You do not control the update cycle of the client layer

2. You want to decouple platform support. You can do this for technical reasons and for org reasons (you can scale up teams independently)

This way, you can have the client be simple with a slow update cycle. You restrict its slowness to it alone and not to the whole product. You can then scale your backend services teams independently. You can throw away entire backend services while your front-end team modifies their API layer to ensure that legacy clients can handle things. The front-end team working on a client with a slow upgrade cycle can mock API responses or something. Meanwhile, the front-end team that's working on a client with a fast upgrade cycle can just move on.

You can thin your platform-specific client and move more logic into the platform-specific backend while keeping your platform-agnostic backend moving fast.

Correct me if you are wrong but you are saying why does IOS, Andriod, ect each have there own API gateway vs sharing one correct?

Besides different front ends needing different api calls/contracts I have not seen a good explanation yet.

BFF does solve an issue with securing front end JS sites. See here for an explanation: https://docs.duendesoftware.com/identityserver/v5/bff/overvi...

You need to be aware of some lifecycle aspects when dealing with first versus third-party clients. If you don't have experience with third-party being a key component of your business model then this is hard to grasp.

When you list these mobile clients, I immediately assume that these are your first-party clients. These are clients which you deploy to various stores and manage completely. There is some chance that you are supporting old versions, but you are mostly in control and can drive the support lifecycle by deprecating old clients when analytics suggest it is OK.

When you have clients that are critical to your business (some weird set-top box) that you can't just deprecate, then it starts to become viable to do something like this. Your main system can evolve and grow leaving only a single system to maintain for these special clients. Whether it's worthwhile is going to be completely dependent on the value of the client. It's massive improvement in the quality of life for your backend team and those responsible for supporting the client.

No, he's saying that a single api gateway can serve all clients.

By decoupling the BFF APIs which are geared towards a UI specifically, in a way you are moving a big part of the logic and orchestration to the backend and keeping the UI layer super lite. From practical experience, this has been a very helpful pattern both in my startups and enterprise career.

After Googling, I found that we can use both API Gateway (e.g., Apache APISIX, https://apisix.apache.org/blog/) and GraphQL to achieve this:

1. GraphQL: Let developers choose which resources to receive. 2. API Gateway: Except for implementing BFF, also we could filter requests to make sure upstream service is protected. (It's more flexible IMO)

For our app the back of the frontend provides the working data model.

So for our web app we have a next style server side renderer + serverless functions

For the mobile app we stick we a queue based architecture (the web back of the frontend resolves to the same underlying data structure.)

So imo different front ends have different use cases. But in general the back of the frontend isn’t a backend it’s the frontend server. So the round trip is the same for first paint, api requests etc. For the web app at least

1. Use a single traffic receiver at both the browser application and the terminal application. This thing works like a load balancer. It receives messages from a network and sends them where they need to go. There is only 1 place to troubleshoot connectivity concerns. You can still choose between monolith and multi-service applications and have as many micro services as you want.

2. Reduce reliance on HTTP. HTTP is a unidirectional communication technology with a forced round trip. That is a tremendous amount of unnecessary overhead/complexity. I prefer a persistent websocket opened from the browser. Websockets are bidirectional and there is no round trip. This means no more polling the server for updates. Instead everything is an independent event. The browser sends messages to the server at any time and the server independently sends messages to the browser as quickly as it can, which is real time communication happening as quickly as your network connection has bandwidth and your application can process it.

I would like for there to be solutions to the problems identified in this article. I don't have them, and I also would like for the solutions to not be the ones laid out in this article. Better to build something new (?) than to put these band-aids on the existing framework.

There are a number of downsides to graphql that arise from its overly generic (and yet, at the same time, not generic enough) nature. No HTTP caching of graphql requests is one. Very deeply nested payloads is another. Difficulty of expressing complex query logic through parameters. Inability to natively represent structures such as trees of unknown depth. Special efforts spent on preventing arbitrarily deep/complex queries. And so on.

A BFF does not have any of these problems. It can be made as closely tailored to a particular frontend as possible. It does not need to concern itself with a generic use case.

https://docs.wundergraph.com/docs/use-cases/backend-for-fron...

I am pretty certain that the only reason why BFF were invented is for security in mobile and SPA applications, to securely deal with OAuth tokens.

If you don’t need that don’t use a BFF, keep things simple. Start by not building a SPA when it can be a classic server client web app. I feel like most of the web should just be that.

If for whatever reason you don't want to call a few REST endpoints to render some stuff, then you should probably replace those endpoints with some other technology.

> You probably shouldn’t implement microservices.

Because the whole article just seems like making more problems on top of your existing problems.

The big issue I've been seeing is that occasionally frontend teams will decide to develop "features" by stringing together massive series of calls to the backend to implement logic that a singular backend could do much more efficiently. For example, they commonly will have their backend-for-frontend attempt to query large lists of data, even walking through multiple pages, in order to deliver a summary that a backend service could implement in a SQL query. Unnecessary load on the backend service and on the DB to transmit all that data needlessly to the BFF.

I know the easy answer is to blame the frontend devs, but this pattern seems to almost encourage this sort of thing. Frontends try to skip involving the backend teams due to time constraints or just plain naivety, and suddenly the backend team wakes up one morning to find a massive increase in load on their systems triggering alerts, and the frontend team believes its not their fault. This just feels like an innate risk to promoting a frontend team to owning an individual service living in the data center.

i have seen this first hand with a customer. to their credit, they didn't even have a backend team, until i was brought on board to help them rewrite some of their slower frontend functionality into some more efficient backend functions

Hard to understand from just text and the concepts.

Your frontend team needs an API call that retrieves only friend requests with user names/avatars because the current API call is too heavy.

Normally they'd go to the back-end team and ask them to add an endpoint or modify an existing endpoint to give them the exact data they need. The problem with that is global API surface area becomes more complicated. Complexity is bad because more mistakes are made.

With this model your front-end team can implement the endpoint themselves in the BFF and model the response data exactly as they need it.

They also don't need to deal with that one zealot on the back-end team that gives everyone a hard time about tiny irrelevant issues.

Basically, the whole frontend/backend distinction is a simplification. There are more than two layers. And you can probably even identify layers in the frontend as well these days given that a typical SPA actually does a lot of stuff before it even talks to a server. Local browser storage for example is a storage layer. And you probably have some layer in between that and e.g. event handlers.

The reason the frontend/backend boundary is important is because they are physically separated by a network but also have relatively independent life cycles. You don't update them at the same time for example. You might have different versions of the frontend talking to the same backend. Or even multiple different frontend applications. And many companies have multiple backends as well. So, it's an ecosystem of frontends and backends talking to each other. Providing some kind of facade layer for that complexity is of course an obvious solution when you have a complicated backend with its complexity spilling over to frontend layers.

I don't like the terms front-end and back-end. In reality applications are using a variety of internal & external services these days, and not all of them are behind a backend necessarily. Your own micro-services are meant to be used in much the same way as any third party's endpoint.