4 ms·

You can see how dysfunctional your backend is by the number of JOINs your frontend people need to make. I call it frontend JOIN ratio. At a job I worked at "fi

You can see how dysfunctional your backend is by the number of JOINs your frontend people need to make. I call it frontend JOIN ratio. At a job I worked at "fix it in the frontend" was a running joke.

karmakaze 3y ago
I also see the opposite where a company has a web app product and a public API. The API is also a product. Some front-end developers think the API is the webapp's API and they shouldn't have to make any tradeoffs. My suggestion in these cases, is to give the front-end devs a node/express server where they can compose the API calls the way they like and consume that from the webapp. But... they have to own it.
- nerdix 3y ago
  This is also known as BFF (Backend For Frontend). Every client gets it's own API tailored for it's use case that will mostly just aggregate/orchestrate calls to the general purpose API. https://samnewman.io/patterns/architectural/bff/ https://samnewman.io/patterns/architectural/bff/
  - DanielHB 3y ago
    Some companies take this even further with a BFF for web, another for Android and another for iOS
    - cqqxo4zV46cp 3y ago
      I’d still put that in the same bucket really. It’s implicitly “a back end for a front end”
klysm 3y ago
This is something I struggle with a lot in API design. If the frontend is to never join, then the backend has to provide either: 1. a very dynamic API (e.g. GraphQL) and support arbitrary queries 2. a static but 'bloated' API where every query joins in too much data to cover every use case 3. a static but 'wide' API where each use case gets its own specially crafted response I have no good answer for what makes sense but I usually straddle 2 and 3.
- solarkraft 3y ago
  If GraphQL was actually a query language (as in: allowing you to change the result set, not only the result shape), maybe 1 would be easily possible. Intuitively I would like that. 3 seems to be the most pragmatic option to me when you have good control over each side.
  - klysm 3y ago
    Supporting the interface of graphql from the backend though is usually not very easy - you usually end up with a half baked database implementation that wraps a better database
  - qazxcvbnm 3y ago
    Can you elaborate on what you mean by changing the result set as opposed to the shape?
  - nicwolff 3y ago
    Huh? GraphQL field arguments are used to filter and paginate result sets.
- dustingetz 3y ago
  this is the problem electric clojure solves: https://github.com/hyperfiddle/electric https://github.com/hyperfiddle/electric
- DanielHB 3y ago
  It depends a lot on the product, how wide and deep your API is and the division of labor. Like are frontend and backend separate teams? do people do full stack? At some point there will be a need for some "bloated" API requests. GraphQL can help minimize how many of those you need.
j-j-j-j 3y ago
Good example why using HTMX is usually a great idea. You can do your joins right there in the DB, it's easy and natural. SPAs are only a good idea if you ignore all the complexity required to make them actually work decently - like carrying over the whole data model all the way to the frontend app.
- DanielHB 3y ago
  This is also why SSR JS frameworks are gaining traction. But I still think as a product grows eventually you need some kind of formal API to help separate concerns and scale teams. Even back in the multi-page application days people doing large apps were already splitting their code MVC style with a model-layer that functions much like an API layer does today in an SPA. Most devs don't understand that some techniques just don't work after a certain point and others are too complex for simple use cases. Everybody wants their silver bullet...
  - PH95VuimJjqBqy 3y ago
    there's nothing wrong with the browser doing work for the rendering, the issue is that _all_ of the work has been offloaded to the browser. It used to be, a page that was primarily rendered on the server but used javascript for dynamicism in the frontend was still considered SSR. nowadays people try to relegate SSR to only rendering on the server, but that's never been the case and is a strawman.
ilaksh 3y ago
That's an interesting comment because while the author was clearly defining front end as HTML and CSS, you went to a layer with joins. Joins used to always be considered a back end activity. I think it's very contextual but in relation to the article they may also be what the author considers to be backend. But I guess now with things like Supabase joins in the front end are normal? It's weird how these things change. But regardless, worth noting that people are using "frontend" to mean different things.
- kiwicopple 3y ago
  Supabase maintainer here, I’m not sure why we would be the driver for joins on the frontend - that’s not necessary or recommended in supabase
  - ilaksh 3y ago
    I think what I meant was that the join can be caused by the front end code, even if it happens on the back end server: https://supabase.com/docs/guides/database/joins-and-nesting https://supabase.com/docs/guides/database/joins-and-nesting "The data APIs automatically detect relationships between Postgres tables. Since Postgres is a relational database, this is a very common scenario." There will be many people with the title Full Stack or Front End engineer who are using Supabase in this way and they may consider the code that triggers this to be front end code. There might or might not be another engineer who is in charge of the database and does some coding for it but always refers to him/herself as "backend" and is not aware that some of these joins are happening and need indices.
- DanielHB 3y ago
  By frontend JOINs I mean backend APIs with so little regard to the client that the client needs to over-fetch data and perform JOINs/GROUP BYs in the client. Very common in companies that keep their backend and frontend teams separate or companies with very dogmatic backend people.

karmakaze 3y ago

I also see the opposite where a company has a web app product and a public API. The API is also a product. Some front-end developers think the API is the webapp's API and they shouldn't have to make any tradeoffs. My suggestion in these cases, is to give the front-end devs a node/express server where they can compose the API calls the way they like and consume that from the webapp. But... they have to own it.

nerdix 3y ago
This is also known as BFF (Backend For Frontend). Every client gets it's own API tailored for it's use case that will mostly just aggregate/orchestrate calls to the general purpose API. https://samnewman.io/patterns/architectural/bff/ https://samnewman.io/patterns/architectural/bff/
- DanielHB 3y ago
  Some companies take this even further with a BFF for web, another for Android and another for iOS
  - cqqxo4zV46cp 3y ago
    I’d still put that in the same bucket really. It’s implicitly “a back end for a front end”

klysm 3y ago

This is something I struggle with a lot in API design. If the frontend is to never join, then the backend has to provide either: 1. a very dynamic API (e.g. GraphQL) and support arbitrary queries 2. a static but 'bloated' API where every query joins in too much data to cover every use case 3. a static but 'wide' API where each use case gets its own specially crafted response I have no good answer for what makes sense but I usually straddle 2 and 3.

solarkraft 3y ago
If GraphQL was actually a query language (as in: allowing you to change the result set, not only the result shape), maybe 1 would be easily possible. Intuitively I would like that. 3 seems to be the most pragmatic option to me when you have good control over each side.
- klysm 3y ago
  Supporting the interface of graphql from the backend though is usually not very easy - you usually end up with a half baked database implementation that wraps a better database
- qazxcvbnm 3y ago
  Can you elaborate on what you mean by changing the result set as opposed to the shape?
- nicwolff 3y ago
  Huh? GraphQL field arguments are used to filter and paginate result sets.
dustingetz 3y ago
this is the problem electric clojure solves: https://github.com/hyperfiddle/electric https://github.com/hyperfiddle/electric
DanielHB 3y ago
It depends a lot on the product, how wide and deep your API is and the division of labor. Like are frontend and backend separate teams? do people do full stack? At some point there will be a need for some "bloated" API requests. GraphQL can help minimize how many of those you need.

j-j-j-j 3y ago

Good example why using HTMX is usually a great idea. You can do your joins right there in the DB, it's easy and natural. SPAs are only a good idea if you ignore all the complexity required to make them actually work decently - like carrying over the whole data model all the way to the frontend app.

DanielHB 3y ago
This is also why SSR JS frameworks are gaining traction. But I still think as a product grows eventually you need some kind of formal API to help separate concerns and scale teams. Even back in the multi-page application days people doing large apps were already splitting their code MVC style with a model-layer that functions much like an API layer does today in an SPA. Most devs don't understand that some techniques just don't work after a certain point and others are too complex for simple use cases. Everybody wants their silver bullet...
- PH95VuimJjqBqy 3y ago
  there's nothing wrong with the browser doing work for the rendering, the issue is that _all_ of the work has been offloaded to the browser. It used to be, a page that was primarily rendered on the server but used javascript for dynamicism in the frontend was still considered SSR. nowadays people try to relegate SSR to only rendering on the server, but that's never been the case and is a strawman.

ilaksh 3y ago

That's an interesting comment because while the author was clearly defining front end as HTML and CSS, you went to a layer with joins. Joins used to always be considered a back end activity. I think it's very contextual but in relation to the article they may also be what the author considers to be backend. But I guess now with things like Supabase joins in the front end are normal? It's weird how these things change. But regardless, worth noting that people are using "frontend" to mean different things.

kiwicopple 3y ago
Supabase maintainer here, I’m not sure why we would be the driver for joins on the frontend - that’s not necessary or recommended in supabase
- ilaksh 3y ago
  I think what I meant was that the join can be caused by the front end code, even if it happens on the back end server: https://supabase.com/docs/guides/database/joins-and-nesting https://supabase.com/docs/guides/database/joins-and-nesting "The data APIs automatically detect relationships between Postgres tables. Since Postgres is a relational database, this is a very common scenario." There will be many people with the title Full Stack or Front End engineer who are using Supabase in this way and they may consider the code that triggers this to be front end code. There might or might not be another engineer who is in charge of the database and does some coding for it but always refers to him/herself as "backend" and is not aware that some of these joins are happening and need indices.
DanielHB 3y ago
By frontend JOINs I mean backend APIs with so little regard to the client that the client needs to over-fetch data and perform JOINs/GROUP BYs in the client. Very common in companies that keep their backend and frontend teams separate or companies with very dogmatic backend people.