[lmm]

No, our backend serves all the queries that the frontend uses, but (in prod) only the queries that the frontend uses - we compile the queries at build time. When we want to add a new query we figure it out in dev (which allows non-compiled queries, but is not accessible for people outside the company), write it in the frontend, and it will be included in the next build of the backend. This is all pretty basic off the shelf functionality. Maybe spend 5 minutes trying to think about how a system might work instead of assuming everyone else is an idiot.

[SpaceNugget]

Yea so you have to add the compiled queries to your back-end to be able to get them on prod, which is what you came out swinging against with a somewhat strongly worded to level comment berating people who choose to not use graphql for having to deal with. Exactly what you just described doing is what the parent comment expected you were doing.

[lmm]

> Yea so you have to add the compiled queries to your back-end to be able to get them on prod, which is what you came out swinging against with a somewhat strongly worded to level comment berating people who choose to not use graphql for having to deal with.

What are you talking about?

The build process takes the queries the frontend wants to use, compiles them, and includes them in the backend build. There is no manual step, you don't even change a single line of code or config on the backend, much less write a new endpoint. As far as I'm aware this is the completely normal way to use graphql.

[solatic]

I think I finally understand your earlier comment in context:

> You can write each endpoint by hand instead of using GraphQL, but it's like writing your own collection datatypes instead of just pulling in an existing library.

Everyone else is "pulling in an existing library", they have names like Express and Kysely, and thinking that Apollo is the only library that deserves this designation is a bit of a head-scratcher.

If you take the time to invest in a proper REST API first, odds are the endpoint may already exist, and you may not need to wait for a new backend build; not investing in a custom endpoint for every frontend change unless real-world performance requirements actually dictate it. You get tooling that is more mature and easier to maintain as a result, makes it easier for Product to experiment (remember: not forcing a backend change for every frontend change), and not using a fad-of-the-month just because it came out of a FAANG.

[lmm]

> If you take the time to invest in a proper REST API first, odds are the endpoint may already exist, and you may not need to wait for a new backend build; not investing in a custom endpoint for every frontend change unless real-world performance requirements actually dictate it. You get tooling that is more mature and easier to maintain as a result, makes it easier for Product to experiment (remember: not forcing a backend change for every frontend change)

If it's a giant system where your backend/frontend/product teams are separate, maybe - but even then, they can run any custom queries they want on non-prod instances, so it's easy to do internal testing, and always including backend deployment when you do a prod release is not a huge burden.

I still think there's never going to be an advantage to doing N+1 queries - there might be cases where the performance difference doesn't matter, but an endpoint that returns precisely what you want would always be better if you could get it for free. And you can't really set up "aggregating" endpoints ahead of time, unless you pre-emptively create all N*N possible combinations, and that's going to go against having a "clean" normalised set of REST endpoints. Just like in a database schema, there's value in having every individual endpoint orthogonal and then doing the joining at query time, at least for a system under active development where you want to try new things without redoing your whole dataflow.

> not using a fad-of-the-month just because it came out of a FAANG.

I don't think it's a fad at this point - graphQL has been around for 10 years, the systems I've worked on have been using it successfully for about 5, and the design is built on what the likes of Thrift and gRPC were already doing where possible. There are, as you pointed out, multiple library implementations for many languages. It's popular because it works.