What I should've said: GraphQL isn't the only option for type safety and preventing over fetching. There's a nice REST pattern which Remix happens to do.
Graphql is designed to be flexible for when you want to expose your data to many clients who may be other teams and need different models of the data.
Obviously, if you just need a simple consistent API, there's no need for all the extra complexity.
My thinking here was kind of half-baked.
Thinking through it some more: - Maybe it's more that I've seen teams reach for GraphQL when another option would've been simpler. - You can get many of GraphQL's benefits with other, simpler solutions. - But when you do need GraphQL, of course go for that.
Maybe thinking through what I was thinking a bit more:
GraphQL isn't the only option for preventing overfetching, and has some downsides. For example, the pattern Remix uses.
GraphQL from a Remix loader is doable. Works great if you have an existing GraphQL you want to consume.
If you don't, though, I prefer avoiding the extra HTTP request.
REST/GraphQL is the result of different teams/orgs working on frontend and backend.
Backend-for-frontend/Remix is the result of the same team working on frontend and backend.
