5 ms·

Simplify that to: - REST by default - everything else might be an option, but you need to justify it with specific reasons. Also, having a JS-driven front en

by timr 4y ago

Simplify that to: - REST by default - everything else might be an option, but you need to justify it with specific reasons. Also, having a JS-driven front end or multiple teams is not an automatic justification for the complexity of GraphQL. GraphQL is a huge burden, for very little practical gain. Most companies have very small number of examples of conflict areas where queries need to be optimized, and for the most part, these can be resolved through smarter front-end engineering (like not throwing React at CRUD websites). It's amazing how we managed to build large-scale websites with essentially all modern functionality without all of this stuff for years and years, and only since 2012 or so have these tools become "necessary" (and I'm being generous with 2012...it's more recent than that).

jensneuse 4y ago
I more or less agree, but recent advances in tooling has changed this. E.g we've built a GraphQL to JSON RPC compiler [0], so we're hiding GraphQL behind a JSON RPC wall which also enables powerful code generation. We're using this successfully to build our own cloud [1] using our own tooling and I quite like it. Shameless plug, I'd love to get feedback if you have the time to try it out. [0]: https://docs.wundergraph.com/docs/features/graphql-to-json-rpc-compiler https://docs.wundergraph.com/docs/features/graphql-to-json-r... [1]: https://cloud.wundergraph.com https://cloud.wundergraph.com
- timr 4y ago
  I mean...ok, but...wow. You built a compiler?? For writing a web app? And you're not Facebook? Look, maybe this is totally appropriate for your application domain. I don't know. But this kind of "power" is immensely complex. We have to be honest about the costs. I have to keep reminding people that essentially all functionality of the modern web existed prior to 2012.
  - deleted 4y ago
    [deleted]
  - satvikpendem 4y ago
    Their entire company is developer tooling with GraphQL, so it's not like they made a compiler for their own specific web app; they're selling their service. I agree if you're just making a run of the mill web app that it's crazy but they're an infrastructure company, not a web app company.
- deleted 4y ago
  [deleted]
- 4RealFreedom 4y ago
  Maybe I'm just not understanding the use case here but your using graphql with a compiler to produce rest (JSON RPC) endpoints? Why not just write rest endpoints? I can see how it might be easy for simple endpoints but as soon as you have to optimize anything you'll need to add features to your compiler.
  - chrisandchris 4y ago
    Sometimes we just need to create another immensly complex layer on top of something, because the 10-year-old boring technology that already works is lame.
IceDane 4y ago
How is GQL a "huge burden"? Would you care to elaborate?
- timr 4y ago
  I could write a book on this, but just a few: * your teams will now spend a big portion of their time thinking about GQL primitives and mapping and syntax (oh my) and otherwise caring for and feeding this beast. * you still haven't solved the underlying problem -- you still have to figure out why your GQL requests are hammering the back-end(s...let's not forget that a lot of this stuff came from poor decision-making re: microservices!), only now it's indirected and harder to optimize. * ...oops, you forgot to implement all the corner cases of your GQL schema! Go back to 1 and start over. Say what you will about REST, but the syntax is dead simple, it takes about 15 minutes to learn, and the semantics are crystal clear. Whatever complexity remains is actual complexity in your problem or org structure, and you should probably just fix that instead of trying to find magical tech beans to abstract the problem away.
  - IceDane 4y ago
    > * your teams will now spend a big portion of their time thinking about GQL primitives and mapping and syntax (oh my) and otherwise caring for and feeding this beast. What exactly do you mean by this? My team spends exactly zero time "thinking about GQL primitives and mapping and syntax"? What programmers have a problem understanding GQL syntax? I have explained GQL and set people to work in a 30 minute session. I've even had non-technical people write automated tests for APIs. If they can't write the queries themselves, they can simply use any of the great query builders(like apollo studio or what have you), where they can quite literally explore the entire schema, with documentation, and point-and-click their way through building any query. > * you still haven't solved the underlying problem -- you still have to figure out why your GQL requests are hammering the back-end(s...let's not forget that a lot of this stuff came from poor decision-making re: microservices!), only now it's indirected and harder to optimize. How is this really any easier with RESTish APIs? In the end, this boils down to how you are doing observability. If you don't do any observability, you are shit out of luck whether you use GQL or REST. With GQL, you can quite literally automatically instrument your entire schema and get detailed tracing information for your entire graph. I have sentry set up to trace all our requests from our frontend, to our GQL gateway, to the subgraphs, to other services they call out to and even time taken doing database queries. It was a few lines of code. > * ...oops, you forgot to implement all the corner cases of your GQL schema! Go back to 1 and start over. Corner cases? If you have some underlying data you need to expose, the difficulty of exposing this data in the most appropriate manner comes down to the complexity of your data, and whether you use GQL or REST to expose it doesn't really change it. With GQL, types and relations are at least "native" - they are the source of truth. With REST and something like OpenAPI, you'll constantly be fighting limitations and have to trawl through hundreds of endpoints, some of which might be doing extra stuff for the sake of ease of consumers, etc. Feel free to elaborate on what sort of corner cases you have in mind. This sort of vague hand-waving isn't really useful.
chiefalchemist 4y ago
I haven't used it a lot but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price. Also, as I understand it, when implemented properly, you can get more complex (?) data back. For example, instead of getting 10 orders, and then 10 more requests for the items for each order, you can make a single request and get both in a single response. I believe both concepts apply to creates / updates as well.
- timr 4y ago
  > but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price. Sort of (the sibling comment explains well why this example is an illusion). But even if this were an advantage, you have to implement the logic (simple in this case, but not so simple once people go hog-wild with the GQL). Also, I don't think I've ever had a situation in my career where loading name and price is a significant burden over either field individually. On the other hand, it's a huge burden to have to implement the back-end system that supports a fully orthogonal, structured query language for the UI. To be fully charitable to the argument you're making, probably the real reason people do this is because they want to decouple development between Team UI and Team Product and Team Pricing, and it's just "easier" to expose "web SQL" to Team UI and let them go nuts, rather than sitting down with them an exposing targeted endpoints that give them exactly what they need. ...but now you have N problems. Your web app has become an ad-hoc distributed query language executor, and you have to think about the semantics and load implications of all of that.
  - lmarcos 4y ago
    > probably the real reason people do this is because they want to decouple development between Team UI and Team Product and Team Pricing, and it's just "easier" to expose "web SQL" to Team UI and let them go nuts, rather than sitting down with them an exposing targeted endpoints that give them exactly what they need. That's the only reason why teams use GraphQL. Decoupling taken to the extreme.
nonethewiser 4y ago
There is a fair amount of practical gain in terms of specifying fields. Can go a long way in terms of making flexible endpoints that don’t pass around extra data. This often isn’t necessary. But when it is you would cry at the thought of using REST instead.
- timr 4y ago
  I can think of painful examples in REST in my life where I had an endpoint that was being used for something new, and now I had to join with some new data model to solve the new problem which made the old use sub-optimal (or vice-versa). But when that happened, what it really told me was that it was time to introduce a new endpoint and refactor the code to adapt to the change in use case. Painful? Sure. But so are the downstream consequences of converting everything in your system to an arbitrary query executor.
  - nonethewiser 4y ago
    Right. In GraphQL you wouldn’t need to make a new endpoint for the same resource just because you’re calling it for a different purpose. It separates the API from how it’s used. If you’re querying different fields on the same resource 50 different times it’s rather absurd to keep making new endpoints.
    - timr 4y ago
      > GraphQL you wouldn’t need to make a new endpoint for the same resource just because you’re calling it for a different purpose. Yes, but I'm saying that's a feature, not a bug. It's not absurd to make new endpoints. Each endpoint is a different need. You can optimize them independently...or not. > If you’re querying different fields on the same resource 50 different times it’s rather absurd to keep making new endpoints. In my career, I can count the number of times that a field has mattered in a response on one hand. Usually the problem is the joins, or the total number of queries. Point being: you don't generally write new endpoints just because the number of fields in a response is slightly different.
Shish2k 4y ago
> GraphQL is a huge burden I’ve recently been bolting graphql support onto a midsize legacy webapp with the goal of making native mobile apps easier, and so far I’ve been finding it remarkably simple and delightful — In fact implementing a graphql API so that the clients can specify which data they want for themselves has taken less time than all the design dicsussions about what a REST API could potentially look like… (edit: originally I asked how it was a burden, but after refreshing the page I see this was already discussed in another subthread, so I’ll just throw in my anecdote without asking any question :) )
- timr 4y ago
  It's one those "the first taste is free" kind of things. If you're just doing the transition now, you'll have to take my word that there's more pain coming. It also matters a lot what you mean by "bolting on"...is anyone on the team actually using it? I will freely admit that, depending on the size of the team and the scale of the app, YMMV. For example, if you're the only person working on a legacy app that isn't under high load or lots of regular change, it probably doesn't matter what technology you use. At the extreme other end, the best tech in the world can be an impossible lift for a high-load service with a huge team supporting it. Most of the parasitic complexity, in my experience, comes not from GQL itself, so much as the downstream burdens that come with maintaining the infrastructure needed to service the GQL. Everything being a POST, for example -- hope you don't like cacheing!
  - zelphirkalt 4y ago
    Also it matters, what kind of security requirements there are. Is it an API, that everyone can query to their heart's content? Or is there stuff some people may access and others are not allowed to see? Then suddenly there is a whole security layer in the game, that needs to be carefully implemented and tested. Did the thing I implement really protect the data of the API from all possible accesses by unauthorized people?
unusualmonkey 4y ago
> GraphQL is a huge burden, for very little practical gain. Most companies have very small number of examples of conflict areas where queries need to be optimized, and for the most part, these can be resolved through smarter front-end engineering (like not throwing React at CRUD websites). We use Hasura to provide GraphQL and find the exact opposite. * Need to filter by X? Already done. * Want to join two different entities? Done. * Pagination? Done. * Aggregation? Done. * Security? Done, just set it. * Streaming data? Done. We don't have traditional API code, and yet have an API is more sophisticated and powerful than any API I've built professionally.
- jasfi 4y ago
  Caching as an option is also good.
arwhatever 4y ago
Do teams tend to use GraphQL Schema to synchronize syntactic expectations between FE and BE? My experience in doing so is limited, but I do know that this synchronization tends to be difficult and really like the idea of an explicit contract-based synchronization strategy. It seems like a very big potential benefit but again, I don’t have enough direct experience doing too so be willing to put much stake in defending it.

by timr 4y ago

jensneuse 4y ago

I more or less agree, but recent advances in tooling has changed this. E.g we've built a GraphQL to JSON RPC compiler [0], so we're hiding GraphQL behind a JSON RPC wall which also enables powerful code generation. We're using this successfully to build our own cloud [1] using our own tooling and I quite like it. Shameless plug, I'd love to get feedback if you have the time to try it out. [0]: https://docs.wundergraph.com/docs/features/graphql-to-json-rpc-compiler https://docs.wundergraph.com/docs/features/graphql-to-json-r... [1]: https://cloud.wundergraph.com https://cloud.wundergraph.com

timr 4y ago
I mean...ok, but...wow. You built a compiler?? For writing a web app? And you're not Facebook? Look, maybe this is totally appropriate for your application domain. I don't know. But this kind of "power" is immensely complex. We have to be honest about the costs. I have to keep reminding people that essentially all functionality of the modern web existed prior to 2012.
- deleted 4y ago
  [deleted]
- satvikpendem 4y ago
  Their entire company is developer tooling with GraphQL, so it's not like they made a compiler for their own specific web app; they're selling their service. I agree if you're just making a run of the mill web app that it's crazy but they're an infrastructure company, not a web app company.
deleted 4y ago
[deleted]
4RealFreedom 4y ago
Maybe I'm just not understanding the use case here but your using graphql with a compiler to produce rest (JSON RPC) endpoints? Why not just write rest endpoints? I can see how it might be easy for simple endpoints but as soon as you have to optimize anything you'll need to add features to your compiler.
- chrisandchris 4y ago
  Sometimes we just need to create another immensly complex layer on top of something, because the 10-year-old boring technology that already works is lame.

IceDane 4y ago

How is GQL a "huge burden"? Would you care to elaborate?

timr 4y ago
I could write a book on this, but just a few: * your teams will now spend a big portion of their time thinking about GQL primitives and mapping and syntax (oh my) and otherwise caring for and feeding this beast. * you still haven't solved the underlying problem -- you still have to figure out why your GQL requests are hammering the back-end(s...let's not forget that a lot of this stuff came from poor decision-making re: microservices!), only now it's indirected and harder to optimize. * ...oops, you forgot to implement all the corner cases of your GQL schema! Go back to 1 and start over. Say what you will about REST, but the syntax is dead simple, it takes about 15 minutes to learn, and the semantics are crystal clear. Whatever complexity remains is actual complexity in your problem or org structure, and you should probably just fix that instead of trying to find magical tech beans to abstract the problem away.
- IceDane 4y ago
  > * your teams will now spend a big portion of their time thinking about GQL primitives and mapping and syntax (oh my) and otherwise caring for and feeding this beast. What exactly do you mean by this? My team spends exactly zero time "thinking about GQL primitives and mapping and syntax"? What programmers have a problem understanding GQL syntax? I have explained GQL and set people to work in a 30 minute session. I've even had non-technical people write automated tests for APIs. If they can't write the queries themselves, they can simply use any of the great query builders(like apollo studio or what have you), where they can quite literally explore the entire schema, with documentation, and point-and-click their way through building any query. > * you still haven't solved the underlying problem -- you still have to figure out why your GQL requests are hammering the back-end(s...let's not forget that a lot of this stuff came from poor decision-making re: microservices!), only now it's indirected and harder to optimize. How is this really any easier with RESTish APIs? In the end, this boils down to how you are doing observability. If you don't do any observability, you are shit out of luck whether you use GQL or REST. With GQL, you can quite literally automatically instrument your entire schema and get detailed tracing information for your entire graph. I have sentry set up to trace all our requests from our frontend, to our GQL gateway, to the subgraphs, to other services they call out to and even time taken doing database queries. It was a few lines of code. > * ...oops, you forgot to implement all the corner cases of your GQL schema! Go back to 1 and start over. Corner cases? If you have some underlying data you need to expose, the difficulty of exposing this data in the most appropriate manner comes down to the complexity of your data, and whether you use GQL or REST to expose it doesn't really change it. With GQL, types and relations are at least "native" - they are the source of truth. With REST and something like OpenAPI, you'll constantly be fighting limitations and have to trawl through hundreds of endpoints, some of which might be doing extra stuff for the sake of ease of consumers, etc. Feel free to elaborate on what sort of corner cases you have in mind. This sort of vague hand-waving isn't really useful.

chiefalchemist 4y ago

I haven't used it a lot but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price. Also, as I understand it, when implemented properly, you can get more complex (?) data back. For example, instead of getting 10 orders, and then 10 more requests for the items for each order, you can make a single request and get both in a single response. I believe both concepts apply to creates / updates as well.

timr 4y ago
> but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price. Sort of (the sibling comment explains well why this example is an illusion). But even if this were an advantage, you have to implement the logic (simple in this case, but not so simple once people go hog-wild with the GQL). Also, I don't think I've ever had a situation in my career where loading name and price is a significant burden over either field individually. On the other hand, it's a huge burden to have to implement the back-end system that supports a fully orthogonal, structured query language for the UI. To be fully charitable to the argument you're making, probably the real reason people do this is because they want to decouple development between Team UI and Team Product and Team Pricing, and it's just "easier" to expose "web SQL" to Team UI and let them go nuts, rather than sitting down with them an exposing targeted endpoints that give them exactly what they need. ...but now you have N problems. Your web app has become an ad-hoc distributed query language executor, and you have to think about the semantics and load implications of all of that.
- lmarcos 4y ago
  > probably the real reason people do this is because they want to decouple development between Team UI and Team Product and Team Pricing, and it's just "easier" to expose "web SQL" to Team UI and let them go nuts, rather than sitting down with them an exposing targeted endpoints that give them exactly what they need. That's the only reason why teams use GraphQL. Decoupling taken to the extreme.

nonethewiser 4y ago

There is a fair amount of practical gain in terms of specifying fields. Can go a long way in terms of making flexible endpoints that don’t pass around extra data. This often isn’t necessary. But when it is you would cry at the thought of using REST instead.

timr 4y ago
I can think of painful examples in REST in my life where I had an endpoint that was being used for something new, and now I had to join with some new data model to solve the new problem which made the old use sub-optimal (or vice-versa). But when that happened, what it really told me was that it was time to introduce a new endpoint and refactor the code to adapt to the change in use case. Painful? Sure. But so are the downstream consequences of converting everything in your system to an arbitrary query executor.
- nonethewiser 4y ago
  Right. In GraphQL you wouldn’t need to make a new endpoint for the same resource just because you’re calling it for a different purpose. It separates the API from how it’s used. If you’re querying different fields on the same resource 50 different times it’s rather absurd to keep making new endpoints.
  - timr 4y ago
    > GraphQL you wouldn’t need to make a new endpoint for the same resource just because you’re calling it for a different purpose. Yes, but I'm saying that's a feature, not a bug. It's not absurd to make new endpoints. Each endpoint is a different need. You can optimize them independently...or not. > If you’re querying different fields on the same resource 50 different times it’s rather absurd to keep making new endpoints. In my career, I can count the number of times that a field has mattered in a response on one hand. Usually the problem is the joins, or the total number of queries. Point being: you don't generally write new endpoints just because the number of fields in a response is slightly different.

Shish2k 4y ago

> GraphQL is a huge burden I’ve recently been bolting graphql support onto a midsize legacy webapp with the goal of making native mobile apps easier, and so far I’ve been finding it remarkably simple and delightful — In fact implementing a graphql API so that the clients can specify which data they want for themselves has taken less time than all the design dicsussions about what a REST API could potentially look like… (edit: originally I asked how it was a burden, but after refreshing the page I see this was already discussed in another subthread, so I’ll just throw in my anecdote without asking any question :) )

timr 4y ago
It's one those "the first taste is free" kind of things. If you're just doing the transition now, you'll have to take my word that there's more pain coming. It also matters a lot what you mean by "bolting on"...is anyone on the team actually using it? I will freely admit that, depending on the size of the team and the scale of the app, YMMV. For example, if you're the only person working on a legacy app that isn't under high load or lots of regular change, it probably doesn't matter what technology you use. At the extreme other end, the best tech in the world can be an impossible lift for a high-load service with a huge team supporting it. Most of the parasitic complexity, in my experience, comes not from GQL itself, so much as the downstream burdens that come with maintaining the infrastructure needed to service the GQL. Everything being a POST, for example -- hope you don't like cacheing!
- zelphirkalt 4y ago
  Also it matters, what kind of security requirements there are. Is it an API, that everyone can query to their heart's content? Or is there stuff some people may access and others are not allowed to see? Then suddenly there is a whole security layer in the game, that needs to be carefully implemented and tested. Did the thing I implement really protect the data of the API from all possible accesses by unauthorized people?

unusualmonkey 4y ago

> GraphQL is a huge burden, for very little practical gain. Most companies have very small number of examples of conflict areas where queries need to be optimized, and for the most part, these can be resolved through smarter front-end engineering (like not throwing React at CRUD websites). We use Hasura to provide GraphQL and find the exact opposite. * Need to filter by X? Already done. * Want to join two different entities? Done. * Pagination? Done. * Aggregation? Done. * Security? Done, just set it. * Streaming data? Done. We don't have traditional API code, and yet have an API is more sophisticated and powerful than any API I've built professionally.

jasfi 4y ago
Caching as an option is also good.

arwhatever 4y ago

Do teams tend to use GraphQL Schema to synchronize syntactic expectations between FE and BE? My experience in doing so is limited, but I do know that this synchronization tends to be difficult and really like the idea of an explicit contract-based synchronization strategy. It seems like a very big potential benefit but again, I don’t have enough direct experience doing too so be willing to put much stake in defending it.