4 ms·

A question you should ask yourself at the start that I rarely here any discussion of: how much do you want to expose your backend data model to your front end(s

by injb 3y ago

A question you should ask yourself at the start that I rarely here any discussion of: how much do you want to expose your backend data model to your front end(s)? If your answer is "completely", which it sometimes is, then GraphQL might be a good option. It's only a question of implementation details. If the answer is "not at all" then GraphQL is probably going to be a bad idea because that is the whole point of GraphQL. The reason people don't realize this is because sadly most people's idea of a REST API is already just a plain 1-1 mapping from DB tables to JSON objects served over HTTP. If you're doing that, you're already coupling any front ends or other consumers to your data model, so what do you have to lose with GraphQL (other than the complexity of deploying it)? When REST was coined the goal was to hide as much data model stuff as possible. This is really really important if your backend app needs a high degree of interoperability across organizational boundaries, because data migration is hard! But if your API is consumed only by a small number of components that your organization has total control over, you might not care that much. Years ago I used to see people implementing crude remote procedure call patterns over HTTP because they thought that's what REST was, and had been told it was better because of reasons. But this wasn't a better way of doing remote procedure calls. It was a much worse way! Now I see people using frameworks that just expose all their DB models as HTTP endpoints because they think that's what REST is and have been told it's better. That isn't really what REST is, and GraphQL might be a better way of doing that if that's what you need. REST is a bunch of constraints that make interoperability and scalability easy to achieve. Maybe you benefit from those constraints and maybe you don't. But that's what you need to think about before you think about GraphQL.

plumeria 3y ago
I'm somewhat confused about what you mean by "expose your backend data model to your front end(s)", since you can disable introspection in production.
- injb 3y ago
  The issue I'm talking about is allowing clients to make arbitrary queries via GQL. Maybe I've misunderstood it, but that's how I've seen it used before. If clients can do that, then they need to know about the model. And if they can't then I'm not sure what GQL does that REST doesn't do.
  - patrickthebold 3y ago
    My understanding is "arbitrary queries" <> "arbitrary _database_ queries". So you can have some abstract "graph" that can be queried, and separately implement "resolvers" (IIRC) that actually tie parts of the graph to actual queries. (So there is a layer of indirection.) What you get is a way for clients to tell you precisely what fields it needs and a way for it to coalesce what would be multiple api calls in a REST world into a single request.
    - injb 3y ago
      Thanks, that's a more nuanced understanding of it than I had. Still, when I try to think about keeping that model in sync with the real underlying model, it scares me. It sounds to me like there is still bound to be some correlation between querying flexibility on the client side, and coupling between the client and server. But that is OK in many cases and in fact is how many REST apis are already being implemented.
      - pests 3y ago
        GraphQL exposes your backend model the same way your json response to a REST api exposes the backend model - they dont. It's up to your REST api to assemble data from the database (or elsewhere) and return them in a structured format. GraphQL resolvers do the same. You can hit another API, query a database, or return file data. It's up to you what you want each field to resolve to.
silisili 3y ago
I've always found REST more logical. In a way, it's like the Unix philosophy...do one thing(at a time) and do it well. Implementing Graphql on the backend turns into a clusterf of spaghetti code real quick. And there are a lot of footguns. I've noticed a lot of frontend folks especially like GraphQL, as they just want the data in as few calls as possible, which I can't fault them for. I've read about an apollo bridge that basically does GQL over REST. I'm pretty curious how well that works, because it sounds like the best of both worlds. Clients who want GQL have it, clients that want REST have it, and backend logic itself is massively less complex.
- cheald 3y ago
  Interestingly, the principle of single responsibility is specifically why I like GraphQL over REST. As your frontend complexity grows, your REST payloads tend to become carefully-balanced collections of complex shapes, and it becomes very difficult to maintain and refactor over time. In GQL, by comparison, each field or mutation has its own isolated implementation, authorization is handled at a granular level, and frontend queries can evolve as needed without imposing any significant need for changes on the backend. REST is great for small, compact APIs which serve a couple of views, but as the product grows in scope and complexity, GraphQL ends up feeling significantly easier to keep straight. The other thing is that it's very easy to build "complex" REST APIs on top of GraphQL - execute an internal query, reshape the result into a JSON payload to conform to the REST contract - but implementing GraphQL on top of a bunch of REST calls is a lot hairier. GraphQL feels more like a set of primitives, while REST is a coalesced interface.
- ttfkam 3y ago
  Postgraphile https://postgraphile.org/ https://postgraphile.org/ Hasura https://hasura.io/ https://hasura.io/ Stop writing GraphQL resolvers by hand, especially if you're working off of a relational database model.
  - fswd 3y ago
    writing graphql resolvers by hand was what I did in ... 2017. I've been using postgraphile since and couldn't be happier. I don't think I've written a single line of Apollo in 5+ years. And with postgraphile, and a remix/next BFF, you don't even need a backend!
mikecaulley 3y ago
How you model the data at rest does not need to match the GraphQL specification. The GraphQL specification should be similar to your REST entities but they have traversable edges to other entities.
semiquaver 3y ago
It’s very much possible to keep your backend data model from leaking too much into your GraphQL schema, it’s just more work than for example using some kind of generator that creates a GraphQL schema from your database schema. The harder thing in my experience is to make a GraphQL API that is performant across all edge cases and properly cost-limited. That takes an enormous amount of internal analytics infrastructure and work and is often not worth the effort. And after all that effort, integrators don’t usually want to take the trouble to learn enough GraphQL to actually use the API. I’ve come to the conclusion that GraphQL is a pretty good system for internal APIs for web and mobile, but a pretty poor one for public-facing APIs.
windexh8er 3y ago
Happened to have worked with an API security product for a while that was sitting in front of a lot of large brands. One retailer that had APIs constantly under attack from bot and organized crime invested a lot of time and money into remapping their old rest API such that they could better protect the pieces of it in different ways. Then, out of the blue, we learned they were moving everything to GraphQL because they had done cost analysis on how many fewer calls they'd need to make, creating efficiency gains of over 50% of all session transactions. What they failed to take into account was that all of the time and money invested in the prior methods to protect really relied on the structures of their REST schema. Now everything would need to build back up and many of the security introspection gates were within the chaining of the REST calls which could no longer happen.
ttymck 3y ago
This explanation is evident of a lack of understanding. I should know, because I felt exactly the way you do before I implemented a GraphQL server. Unfortunately, I still don't know how to explain in words why your understanding is inaccurate, I only know how what it means in practice, by example. GraphQL is still elusive in that regard.

by injb 3y ago

plumeria 3y ago

I'm somewhat confused about what you mean by "expose your backend data model to your front end(s)", since you can disable introspection in production.

injb 3y ago
The issue I'm talking about is allowing clients to make arbitrary queries via GQL. Maybe I've misunderstood it, but that's how I've seen it used before. If clients can do that, then they need to know about the model. And if they can't then I'm not sure what GQL does that REST doesn't do.
- patrickthebold 3y ago
  My understanding is "arbitrary queries" <> "arbitrary _database_ queries". So you can have some abstract "graph" that can be queried, and separately implement "resolvers" (IIRC) that actually tie parts of the graph to actual queries. (So there is a layer of indirection.) What you get is a way for clients to tell you precisely what fields it needs and a way for it to coalesce what would be multiple api calls in a REST world into a single request.
  - injb 3y ago
    Thanks, that's a more nuanced understanding of it than I had. Still, when I try to think about keeping that model in sync with the real underlying model, it scares me. It sounds to me like there is still bound to be some correlation between querying flexibility on the client side, and coupling between the client and server. But that is OK in many cases and in fact is how many REST apis are already being implemented.
    - pests 3y ago
      GraphQL exposes your backend model the same way your json response to a REST api exposes the backend model - they dont. It's up to your REST api to assemble data from the database (or elsewhere) and return them in a structured format. GraphQL resolvers do the same. You can hit another API, query a database, or return file data. It's up to you what you want each field to resolve to.

silisili 3y ago

I've always found REST more logical. In a way, it's like the Unix philosophy...do one thing(at a time) and do it well. Implementing Graphql on the backend turns into a clusterf of spaghetti code real quick. And there are a lot of footguns. I've noticed a lot of frontend folks especially like GraphQL, as they just want the data in as few calls as possible, which I can't fault them for. I've read about an apollo bridge that basically does GQL over REST. I'm pretty curious how well that works, because it sounds like the best of both worlds. Clients who want GQL have it, clients that want REST have it, and backend logic itself is massively less complex.

cheald 3y ago
Interestingly, the principle of single responsibility is specifically why I like GraphQL over REST. As your frontend complexity grows, your REST payloads tend to become carefully-balanced collections of complex shapes, and it becomes very difficult to maintain and refactor over time. In GQL, by comparison, each field or mutation has its own isolated implementation, authorization is handled at a granular level, and frontend queries can evolve as needed without imposing any significant need for changes on the backend. REST is great for small, compact APIs which serve a couple of views, but as the product grows in scope and complexity, GraphQL ends up feeling significantly easier to keep straight. The other thing is that it's very easy to build "complex" REST APIs on top of GraphQL - execute an internal query, reshape the result into a JSON payload to conform to the REST contract - but implementing GraphQL on top of a bunch of REST calls is a lot hairier. GraphQL feels more like a set of primitives, while REST is a coalesced interface.
ttfkam 3y ago
Postgraphile https://postgraphile.org/ https://postgraphile.org/ Hasura https://hasura.io/ https://hasura.io/ Stop writing GraphQL resolvers by hand, especially if you're working off of a relational database model.
- fswd 3y ago
  writing graphql resolvers by hand was what I did in ... 2017. I've been using postgraphile since and couldn't be happier. I don't think I've written a single line of Apollo in 5+ years. And with postgraphile, and a remix/next BFF, you don't even need a backend!

mikecaulley 3y ago

How you model the data at rest does not need to match the GraphQL specification. The GraphQL specification should be similar to your REST entities but they have traversable edges to other entities.

semiquaver 3y ago

It’s very much possible to keep your backend data model from leaking too much into your GraphQL schema, it’s just more work than for example using some kind of generator that creates a GraphQL schema from your database schema. The harder thing in my experience is to make a GraphQL API that is performant across all edge cases and properly cost-limited. That takes an enormous amount of internal analytics infrastructure and work and is often not worth the effort. And after all that effort, integrators don’t usually want to take the trouble to learn enough GraphQL to actually use the API. I’ve come to the conclusion that GraphQL is a pretty good system for internal APIs for web and mobile, but a pretty poor one for public-facing APIs.

windexh8er 3y ago

Happened to have worked with an API security product for a while that was sitting in front of a lot of large brands. One retailer that had APIs constantly under attack from bot and organized crime invested a lot of time and money into remapping their old rest API such that they could better protect the pieces of it in different ways. Then, out of the blue, we learned they were moving everything to GraphQL because they had done cost analysis on how many fewer calls they'd need to make, creating efficiency gains of over 50% of all session transactions. What they failed to take into account was that all of the time and money invested in the prior methods to protect really relied on the structures of their REST schema. Now everything would need to build back up and many of the security introspection gates were within the chaining of the REST calls which could no longer happen.

ttymck 3y ago

This explanation is evident of a lack of understanding. I should know, because I felt exactly the way you do before I implemented a GraphQL server. Unfortunately, I still don't know how to explain in words why your understanding is inaccurate, I only know how what it means in practice, by example. GraphQL is still elusive in that regard.