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.

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

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

"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.

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.

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.

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...

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.

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.

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.

Can you elaborate on what you mean by changing the result set as opposed to the shape?

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

Huh? GraphQL field arguments are used to filter and paginate result sets.

this is the problem electric clojure solves: https://github.com/hyperfiddle/electric

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.

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.

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/

Some companies take this even further with a BFF for web, another for Android and another for iOS

I’d still put that in the same bucket really. It’s implicitly “a back end for a front end”