4 ms·
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 c
by 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 agoSupabase 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 agoI 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 agoBy 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.