12 ms·

I never understood why people go for graphql. In my experience, it's a nightmare to 1/ secure 2/ version 3/ ensure qos Securing it properly should make it a n

by x86x87 3y ago

I never understood why people go for graphql. In my experience, it's a nightmare to 1/ secure 2/ version 3/ ensure qos Securing it properly should make it a no-go in like 95% of cases. you get amazing flexibility on the front end with a heavy heavy cost on the backend. Also, in general being able to say "i want to do whatever" and request everything at once is an anti-pattern IMHO, especially after HTTP2 became mainstream and doing multiple requests is reasonably fast. Versioning? Forget about it. Now you have "all the versions" and good luck figuring out what is used, what is not used or god forbid deprecate something. you're going to have a bad time. As far as qos goes, if any client can range from "i'm asking a simple thing" to "i would like the whole world please - and btw you're only going to figure things out as you pull them in" qos becomes a pipe dream. Last, I don't understand what Netflix does that is so complex that would warrant something like gql. I just don't. To the naive developer in me it seems that they 1) need to have a basic api to get whatever catalog they have + a few apps build on top of that 2) have figured out how to do streaming exceptionally well in order to scale to all the people watching. That's is and although a gross oversimplification I cannot think about a scenario where gql is needed. I think in their desire to reinvent the wheel Netflix has jumped the shark. A lot of really good ideas have come out of the innovation they did in the past but lately it seems like they are doing things for the sake of doing them or they are pissing people off with password household policies and whatnot.

downWidOutaFite 3y ago
My main issue with it is client-side caching doesn't map cleanly to graphql. I want well-defined objects to cache.
- gareve 3y ago
  that's solved with Relay's graphstore
  - x86x87 3y ago
    There's a solution to everything /s We started with a somewhat simple problem and now let's keep throwing things in. How about something I can just curl? Is that too much to ask?
    - chrischen 3y ago
      Well, no, Relay is how GraphQL is meant to be used and is Facebook's client implementation and quite opinionated. Apollo and others came around to be less opinionated (and thus allowed people to re-use their old REST style designs) in GraphQL. You can in fact just curl a GraphQL API. In simple projects where I don't need caching I just use the REST library and make a simple HTTP request with a graphql query string. I get back a JSON object to consume.
jdauriemma 3y ago
The state of the art of GraphQL tooling around securing and versioning has evolved significantly. You may want to take another look at what’s out there.
- rblatz 3y ago
  I was just researching graphql versioning and the recommendation is not to version because the graph is supposed to be an evolving entity.
  - x86x87 3y ago
    [flagged]
    - Dudester230602 3y ago
      Put this into the "my code is self-documenting" bin.
      - x86x87 3y ago
        my self-documenting code is evolving!
  - itsmeste 3y ago
    mutation createUser-v2 Seen that in some productive APIs, always fun.
- tnzk 3y ago
  Could you please provide some pointers?
geodel 3y ago
Netflix is large company with huge IT/software workforce. And as I have seem in large companies tech managers and engineers don't usually keep waiting for actual problem to appear and develop solution for it. They are going to take initiative to migrate legacy monolith to next generation micro services, GraphQL architecture and in process save their jobs.
- x86x87 3y ago
  The timing of this is hilarious. Here is something that's on the front page at the same time: https://news.ycombinator.com/item?id=36380711 https://news.ycombinator.com/item?id=36380711
  - geodel 3y ago
    Thanks. Great read. When work or personal issues overwhelm me I go with this kind of meta analysis and stop usually at Keynes quote : In the long run we are all dead. This helps me get though the day.
sibeliuss 3y ago
It's 2023. There are _so many tools and patterns now_.
- x86x87 3y ago
  [flagged]
buro9 3y ago
> I never understood why people go for graphql. It allows a full separation of the frontend dev velocity from the backend velocity. The frontend is no longer dependant on backend engineers for API creation, nor negotiations on how those should look. The backend can choose to observe the hot path of GraphQL and optimise those for your #3, but #1 and #2 don't differ from, say, REST.
- x86x87 3y ago
  So you're solving an organizational problem by using gql? Who needs proper authz/authn, security, scalability, sanity, qos if we can have frontend dev velocity? Checks out.
  - seanp2k2 3y ago
    GraphQL really needs a gateway like Envoy to give better observability / control / auth, and indeed that’s how lots of people deploy it.
    - x86x87 3y ago
      Okay. Tell me how you do the control/auth and allow certain users to access a resource while others do not access it while they may formulate complex queries where they ask for the kitchen sink.
      - andrewingram 3y ago
        By wrapping the code that loads data with code that checks whether the current (i.e. requesting) user is allowed to load that data. I don't really understand the problem, how is this any more difficult than any other API paradigm?
        foota 3y ago
        I think the additional issues come when you want to define access by a relationship instead of just the entity, which means you need to check access based on the edges, and not the nodes. You'd have to do this anyway with REST, but I think it's easier in some ways to make mistakes and allow more access than intended.
hn_throwaway_99 3y ago
Going to reply here because, as a huge fan of GraphQL, I strongly disagree with every single one of your points. To start, I think the biggest misconception I see about the value of GraphQL is people see it as some sort of generic "query language", which is unsurprising, given the name. If anything I think the biggest problem with GraphQL is that, if people just saw it is a simple alternative to REST, with a well defined set of query (GET) and mutation (PUT/POST/DELETE) endpoints, they wouldn't get caught up in all this "infinite object graph" stuff that I never hit in my day-to-day. To your points: 1. I find GraphQL to be fantastic for security, primarily because all calls are strongly typed, so you can ensure by the time a request gets to your resolver it is guaranteed to match the defined input types. Furthermore, I always make heavy use of custom scalar types instead of String, which allows me to get rid of a whole host of potential security issues by limiting potential injection attacks before my code even sees it. As far as ensuring object ownership/permissions, this is trivially easy, or in any case just as easy as with REST. 2. Versioning is one of GraphQL's greatest strengths. The tooling makes it easy to deprecate some fields while adding replacement ones in a way that guarantees backwards compatibility. Far from "good luck figuring out what is used", the tooling e.g. in Apollo makes it very easy to see which clients are making use of which fields. Furthermore, if you do need to "hard version" a new endpoint, you can do it similarly to REST by including a version parameter in your URL (e.g. /v1/myGraphQLEndpoint). 3. Regarding qos, this again just gets to my original point about having well defined queries and mutations. Your queries don't need to say "allow me to see the world" any more than any other API framework. It's not hard to just have queries that only say "give me X by ID" and also a single bulk retrieval endpoint where you define the boundaries of what you want to return. If anything, I think perhaps a lot of misconceptions around the problems of GraphQL have to do with these tools that basically say "expose my whole DB with GraphQL", which in my experience usually leads to tears in the end. But starting with a thoughtful definition of your API surface area with GraphQL's type definition language can make it a joy to use and provides lots of benefits over a straight RESTful interface.
- politelemon 3y ago
  If I'm understanding correctly, there is a lot more work a team has to do to build and maintain a GraphQL API and should only do it if they understand what they're getting into and what its advantages are. It's not for everyone, and everyone shouldn't assume it's for them.
bbbbzzz1 3y ago
In Apollo server you can add directives to your scehma for authz. It's dead simple. I'm surprised how so many HN posts about graphql just slander it. If you go to the website and look at the use case of why it was made, it makes it pretty clear when it could be a good to use. My experience with it has been very straight forward and a joy
- x86x87 3y ago
  [flagged]
  - bbbbzzz1 3y ago
    Feel free to read how to do it https://www.apollographql.com/docs/apollo-server/schema/directives/ https://www.apollographql.com/docs/apollo-server/schema/dire...
  - theturtletalks 3y ago
    My SaaS backend is a GraphQL Server that has single-handedly saved me tons of hours for integrations and coding. The first iteration of the app was using rest and that was a pain. Hitting multiple endpoints to get all the details of an order is not something I miss. On top of that, I get a beautiful playground that acts as a query builder and documentation. Have you actually used GraphQL in production or for a wide-scale project? A lot of these criticisms for GraphQL comes from people who have played with it for an hour and determined it's not good. Give it a real chance and you'll see why big companies are using it and understand why the ecosystem is growing so fast.
    - x86x87 3y ago
      Yes. Used it for a a couple of large projects at BigCo. Was actually brought in to "polish" a few things. One of the original team members thought it was cool. It was a disaster. Uncovered issue after issue. Convinced management to run a bug bounty program through hackerone and I'm going to let you guess what happened. If you're so brave and confident find a good pen tester and let them have a go at your api. It's a humbling experience.
Rapzid 3y ago
I hate integrating with public GraphQL APIs as well. Give me a REST API pls for the love of god. It makes me sad GitHub's new projects API is GraphQL-Only.
devjab 3y ago
Have you tried the alternatives? We went with Odata, and it's hell. It's fine on the client side, but it's terrible to work with on the server-side. We went down the C# path because everyone else is either using RPC or GraphQL, but even Microsofts own libaries don't work together. The model creatirs for Odata and Entity Framework sort of work the same, but are also different enough to cause some real annoyances and once you add asp.versioning it becomes even worse. We went with Odata because we had a hefty client that consumed Odata through a client library that we build ourselves, and at the time it seemed like it would be fine. A year later it turns out that it would've been better for us to rewrite everything to work with GraphQL, and, we may actually end up doing that eventually because the Odata .NET support is so terrible that we're constantly having to rewrite parts of it to get it do things that are trivial in GraphQL. You can of course go other routes, we took a serius look at tRPC, but it seemed like it would end up being a lot of work. Actually quite similar to how doing the things you want from a frontend perspective is a lot of work if your backend is "just" rest. > Last, I don't understand what Netflix does that is so complex that would warrant something like gql. I just don't. If you dig into the other blog points that the OP link to you can see that it's because they needed better performance, more security and better control of the flow. I think you may underestimate how much you get for "free" when using graphQL. It has so much adoption, that there are so many tools that you won't have to build from scracth, even if you're Netflix. You can see our Odata library as an example of this, there are client libraries that we could've used, but they're bad. So we had to build our own. With GraphQL we wouldn't need to do that.
- x86x87 3y ago
  IMHO, Rest works just fine. If you are serious about performance I don't really get how you do that with GQL. maybe I'm just ignorant but the apps I've worked on were medium to large size and it was a fricking nightmare (apollo-based, a couple of years back). Here: https://hackerone.com/hacktivity?querystring=graphql&filter=type:public&order_direction=DESC&order_field=latest_disclosable_activity_at&followed_only=false&collaboration_only=false https://hackerone.com/hacktivity?querystring=graphql&filter=...
  - valenterry 3y ago
dan-robertson 3y ago
I feel like this is a bad take: I’m not sure what your experience with graphql is but your comments about Netflix strike me as naive. I think there is a simplified version of Netflix that doesn’t do eg recommendation or history or different contracts in different countries and so on, which is maybe just a few api calls, but I don’t think that’s what Netflix is. And are they actually reinventing the wheel here? I thought graphql was a Facebook thing. Maybe you meant to say that they are rewriting systems pointlessly but it (also) feels like a bit of a generic criticism that is easy to apply to companies for which in-house systems make sense. (Edit: it’s not even like this is a graphql vs rest change as Netflix have had graphql for years and they have a custom api system that seems a lot more like graphql than it does rest) I’m curious what you think the best advantages of graphql are, particularly for a larger company like Netflix? I would guess: - reduces coordination/contention between different frontend/backend teams (eg there are many clients – desktop, mobile, various smart devices – but maybe other front ends too like something customer support might use). - cuts down on ‘boilerplate’ api work. For example, maybe you have some property X of each item Y in your catalog, but which you don’t get on the request for the catalog, and that you want to display this now (maybe it’s some new experimental feature you need to thread through from some database table to the front end). You need to choose between adding X to the catalog (potential version woes…) or managing a bunch of requests for X for each Y (risks being slow or bad in a few ways), or add some non-restful api endpoint that takes a list of Ys and gives you their X properties. With graphql you need to teach the backend how to get X of Y but the frontend only needs to change the query. - it potentially lets you apply access controls in a more straightforward way. If someone is from the US, maybe there are some shows they can’t see. In that case we probably want to hide all records in results about shows they can’t see. (Alternative example: various properties of other people’s accounts). If you have many separate api endpoints, it feels easier to me to accidentally screw up on one of them. I’m not really very familiar with graphql but the middle option is the most compelling one for some of the things I work on (which are nothing like Netflix). One assumes that some people from Netflix had reasons for graphql and I’m interested in what they were rather than some imagined Venn diagram with the current api in the ‘not invented here’ area and graphql in the intersection of ‘invented here’ and ‘not yet a thing we have’. I’d also be curious to see how well it works out for them over time – perhaps they’ll regret it but maybe not for the reasons you oppose graphql; if there are organisational problems (like some team becoming a big new bottleneck or some teams being unhappy about it being ‘forced on them’), they can be hard to write about.
pmoriarty 3y ago
GraphQL is such complete and utter garbage for anything but the simplest of queries. I pity anyone who has to use it for anything more complicated.
- x86x87 3y ago
  i would not go as far as saying complete and utter garbage, but it 95% of cases it brings with it a can of worms that you don't need and don't want. All in the name of "frontend developer velocity"!
8note 3y ago
How does http2 skip the speed of light to speed up sequential requests? Isn't the back and forth across the network the big problem?
- x86x87 3y ago
  In the beforefore time, you would need to establish a connection for every request you did if you wanted to make multiple requests in parallel and you were limited by how many request yoi could have in flight in parallel. With http2 you can mux the requests together through the same pipe. Yes, if you need to retrieve A to figure out you need B, it's not going to be "faster" but you would do the same thing on the server side. Also, for a well architected backend you can spread load better on the backend and shockingly you can also leverage caching if you are doing a "dumb" rest api.
  - zeroonetwothree 3y ago
    GraphQL makes it straightforward to do conditional queries like: … on Book { title author if_viewer_can_purchase { price shipping } } This is quite annoying to do with traditional REST without overfetching data you don’t need.
xwowsersx 3y ago
Kong seems to have some offerings on the API gateway security front for GraphQL https://konghq.com/blog/engineering/graphql-authorization-at-the-api-gateway-with-kong-konnect-and-opa https://konghq.com/blog/engineering/graphql-authorization-at... I haven't looked at it very closely yet, but I'm wondering Kong for other reasons (unrelated to GQL)
thrashh 3y ago
GraphQL is like SQL. It’s an extremely leaky abstraction but in the hands of someone experienced, you can do amazing things with a fraction of the effort required. But just like SQL, you have people who happened to learn SQL in passing and it’s like a table saw in the hands of someone who doesn’t know what to do.
Humphrey 3y ago
Both REST and GraphQL API's can be well designed, or badly designed. While I'm a GraphQL fanboy, I would much prefer integrating with a well design REST API over a badly designed GraphQL API. Having spent over 15 years integrating with, and writing API's, GraphQL was a breath of fresh air! If you think of GraphQL as a query language, you will find it frustrating. If you think of it like you do a REST API with all the ugly pain points straightened out and standardised, then it is a dream to work with. GraphQL is as much of a query language as REST is. For example, most REST API's end up getting super long lists of parameters in their urls. How many eCommerce API's end up having REST URL's like: /api/products?category=guitars&include_variants=true&page=20&per_page=100&exclude_fields=description,specs Whereas, GraphQL transforms that into a simple, readable query, which does not require reading pages and pages of documentation to understand. But, if you are creating well designed REST API's, I would prefer to use them over somebodies poorly written Graph. Just like a REST API, a well written Graph should be crafted to be fast and performant to execute. Just like with REST, a Graph designer needs to sit down and think about the ways people will want to use the API. A good graph does not allow endless relationships that will cause performance to blow out.
- rapsey 3y ago
  /api/products?category=guitars&include_variants=true&page=20&per_page=100&exclude_fields=description,specs Seems pretty readable to me.
  - anytime5704 3y ago
    Also, url query parameters are kind of orthogonal to REST vs. GQL. They can complement either API. From personal experience, choosing not to use them (as most single page web apps don’t) can make testing painful and makes deep-linking to specific states of your webpage impossible.
- argentier 3y ago
  > GraphQL is as much of a query language as REST is This doesn't make any sense, unless it's to point out that GraphQL is not a query language at all.
insanitybit 3y ago
> Also, in general being able to say "i want to do whatever" and request everything at once is an anti-pattern IMHO, especially after HTTP2 became mainstream and doing multiple requests is reasonably fast. It's not about performance, it's about being able to trivially get the data you need in one request and get it back in a way that you've structured.
baka367 3y ago
For us the primary value is behind the customizability of it all. One of our main requirements is to give user A LOT of flexibility to customize the default frontend to suit their needs. On top of that we are running DDD in the backend with ARs being spread over multiple different services. We did experiment with rest early on, but we found out that we would need to make our frontned to be extremely complicated and vocal to handle the customization/data fetching requirements or build our own REST gateway on top of open API, doing, essentially, the same thing that graphql gateway does out of the box. Adopting graphql was scary at first with low team exposure to the technology, but using REST would have made our life much much harder
IceDane 3y ago
This rhetoric pops up every time gql is discussed on HN, and it is invariably full of misconceptions and, well, nonsense, that just tells anyone who's actually used gql that you clearly haven't. I never understood why people insist on having strong opinions on things they clearly know nothing about.
PaulHoule 3y ago
People are drawn like moths to a flame to anything that is poorly specified and are repelled by the well-defined. A visit to the ontologist is feared somewhere between a visit to the oncologist and the orthodontist. To be fair, GraphQL has a real specification now but it didn’t back when it was taking off like wildfire.
fbjork 3y ago
GraphQL really shines when it comes to providing a unified data layer for frontend teams. Having a consistent, typed API is a big time saver for developers building data rich applications. The ability for frontend teams to shape the data they need without talking to a backend developer and reduce the number of requests made to the API makes for a perfect match when building high performance applications.

by x86x87 3y ago

downWidOutaFite 3y ago

My main issue with it is client-side caching doesn't map cleanly to graphql. I want well-defined objects to cache.

gareve 3y ago
that's solved with Relay's graphstore
- x86x87 3y ago
  There's a solution to everything /s We started with a somewhat simple problem and now let's keep throwing things in. How about something I can just curl? Is that too much to ask?
  - chrischen 3y ago
    Well, no, Relay is how GraphQL is meant to be used and is Facebook's client implementation and quite opinionated. Apollo and others came around to be less opinionated (and thus allowed people to re-use their old REST style designs) in GraphQL. You can in fact just curl a GraphQL API. In simple projects where I don't need caching I just use the REST library and make a simple HTTP request with a graphql query string. I get back a JSON object to consume.

jdauriemma 3y ago

The state of the art of GraphQL tooling around securing and versioning has evolved significantly. You may want to take another look at what’s out there.

rblatz 3y ago
I was just researching graphql versioning and the recommendation is not to version because the graph is supposed to be an evolving entity.
- x86x87 3y ago
  [flagged]
  - Dudester230602 3y ago
    Put this into the "my code is self-documenting" bin.
    - x86x87 3y ago
      my self-documenting code is evolving!
- itsmeste 3y ago
  mutation createUser-v2 Seen that in some productive APIs, always fun.
tnzk 3y ago
Could you please provide some pointers?

geodel 3y ago

Netflix is large company with huge IT/software workforce. And as I have seem in large companies tech managers and engineers don't usually keep waiting for actual problem to appear and develop solution for it. They are going to take initiative to migrate legacy monolith to next generation micro services, GraphQL architecture and in process save their jobs.

x86x87 3y ago
The timing of this is hilarious. Here is something that's on the front page at the same time: https://news.ycombinator.com/item?id=36380711 https://news.ycombinator.com/item?id=36380711
- geodel 3y ago
  Thanks. Great read. When work or personal issues overwhelm me I go with this kind of meta analysis and stop usually at Keynes quote : In the long run we are all dead. This helps me get though the day.

sibeliuss 3y ago

It's 2023. There are _so many tools and patterns now_.

x86x87 3y ago
[flagged]

buro9 3y ago

> I never understood why people go for graphql. It allows a full separation of the frontend dev velocity from the backend velocity. The frontend is no longer dependant on backend engineers for API creation, nor negotiations on how those should look. The backend can choose to observe the hot path of GraphQL and optimise those for your #3, but #1 and #2 don't differ from, say, REST.

x86x87 3y ago
So you're solving an organizational problem by using gql? Who needs proper authz/authn, security, scalability, sanity, qos if we can have frontend dev velocity? Checks out.
- seanp2k2 3y ago
  GraphQL really needs a gateway like Envoy to give better observability / control / auth, and indeed that’s how lots of people deploy it.
  - x86x87 3y ago
    Okay. Tell me how you do the control/auth and allow certain users to access a resource while others do not access it while they may formulate complex queries where they ask for the kitchen sink.
    - andrewingram 3y ago
      By wrapping the code that loads data with code that checks whether the current (i.e. requesting) user is allowed to load that data. I don't really understand the problem, how is this any more difficult than any other API paradigm?
      - foota 3y ago
        I think the additional issues come when you want to define access by a relationship instead of just the entity, which means you need to check access based on the edges, and not the nodes. You'd have to do this anyway with REST, but I think it's easier in some ways to make mistakes and allow more access than intended.

hn_throwaway_99 3y ago

Going to reply here because, as a huge fan of GraphQL, I strongly disagree with every single one of your points. To start, I think the biggest misconception I see about the value of GraphQL is people see it as some sort of generic "query language", which is unsurprising, given the name. If anything I think the biggest problem with GraphQL is that, if people just saw it is a simple alternative to REST, with a well defined set of query (GET) and mutation (PUT/POST/DELETE) endpoints, they wouldn't get caught up in all this "infinite object graph" stuff that I never hit in my day-to-day. To your points: 1. I find GraphQL to be fantastic for security, primarily because all calls are strongly typed, so you can ensure by the time a request gets to your resolver it is guaranteed to match the defined input types. Furthermore, I always make heavy use of custom scalar types instead of String, which allows me to get rid of a whole host of potential security issues by limiting potential injection attacks before my code even sees it. As far as ensuring object ownership/permissions, this is trivially easy, or in any case just as easy as with REST. 2. Versioning is one of GraphQL's greatest strengths. The tooling makes it easy to deprecate some fields while adding replacement ones in a way that guarantees backwards compatibility. Far from "good luck figuring out what is used", the tooling e.g. in Apollo makes it very easy to see which clients are making use of which fields. Furthermore, if you do need to "hard version" a new endpoint, you can do it similarly to REST by including a version parameter in your URL (e.g. /v1/myGraphQLEndpoint). 3. Regarding qos, this again just gets to my original point about having well defined queries and mutations. Your queries don't need to say "allow me to see the world" any more than any other API framework. It's not hard to just have queries that only say "give me X by ID" and also a single bulk retrieval endpoint where you define the boundaries of what you want to return. If anything, I think perhaps a lot of misconceptions around the problems of GraphQL have to do with these tools that basically say "expose my whole DB with GraphQL", which in my experience usually leads to tears in the end. But starting with a thoughtful definition of your API surface area with GraphQL's type definition language can make it a joy to use and provides lots of benefits over a straight RESTful interface.

politelemon 3y ago
If I'm understanding correctly, there is a lot more work a team has to do to build and maintain a GraphQL API and should only do it if they understand what they're getting into and what its advantages are. It's not for everyone, and everyone shouldn't assume it's for them.

bbbbzzz1 3y ago

In Apollo server you can add directives to your scehma for authz. It's dead simple. I'm surprised how so many HN posts about graphql just slander it. If you go to the website and look at the use case of why it was made, it makes it pretty clear when it could be a good to use. My experience with it has been very straight forward and a joy

x86x87 3y ago
[flagged]
- bbbbzzz1 3y ago
  Feel free to read how to do it https://www.apollographql.com/docs/apollo-server/schema/directives/ https://www.apollographql.com/docs/apollo-server/schema/dire...
- theturtletalks 3y ago
  My SaaS backend is a GraphQL Server that has single-handedly saved me tons of hours for integrations and coding. The first iteration of the app was using rest and that was a pain. Hitting multiple endpoints to get all the details of an order is not something I miss. On top of that, I get a beautiful playground that acts as a query builder and documentation. Have you actually used GraphQL in production or for a wide-scale project? A lot of these criticisms for GraphQL comes from people who have played with it for an hour and determined it's not good. Give it a real chance and you'll see why big companies are using it and understand why the ecosystem is growing so fast.
  - x86x87 3y ago
    Yes. Used it for a a couple of large projects at BigCo. Was actually brought in to "polish" a few things. One of the original team members thought it was cool. It was a disaster. Uncovered issue after issue. Convinced management to run a bug bounty program through hackerone and I'm going to let you guess what happened. If you're so brave and confident find a good pen tester and let them have a go at your api. It's a humbling experience.

Rapzid 3y ago

I hate integrating with public GraphQL APIs as well. Give me a REST API pls for the love of god. It makes me sad GitHub's new projects API is GraphQL-Only.

devjab 3y ago

Have you tried the alternatives? We went with Odata, and it's hell. It's fine on the client side, but it's terrible to work with on the server-side. We went down the C# path because everyone else is either using RPC or GraphQL, but even Microsofts own libaries don't work together. The model creatirs for Odata and Entity Framework sort of work the same, but are also different enough to cause some real annoyances and once you add asp.versioning it becomes even worse. We went with Odata because we had a hefty client that consumed Odata through a client library that we build ourselves, and at the time it seemed like it would be fine. A year later it turns out that it would've been better for us to rewrite everything to work with GraphQL, and, we may actually end up doing that eventually because the Odata .NET support is so terrible that we're constantly having to rewrite parts of it to get it do things that are trivial in GraphQL. You can of course go other routes, we took a serius look at tRPC, but it seemed like it would end up being a lot of work. Actually quite similar to how doing the things you want from a frontend perspective is a lot of work if your backend is "just" rest. > Last, I don't understand what Netflix does that is so complex that would warrant something like gql. I just don't. If you dig into the other blog points that the OP link to you can see that it's because they needed better performance, more security and better control of the flow. I think you may underestimate how much you get for "free" when using graphQL. It has so much adoption, that there are so many tools that you won't have to build from scracth, even if you're Netflix. You can see our Odata library as an example of this, there are client libraries that we could've used, but they're bad. So we had to build our own. With GraphQL we wouldn't need to do that.

x86x87 3y ago
IMHO, Rest works just fine. If you are serious about performance I don't really get how you do that with GQL. maybe I'm just ignorant but the apps I've worked on were medium to large size and it was a fricking nightmare (apollo-based, a couple of years back). Here: https://hackerone.com/hacktivity?querystring=graphql&filter=type:public&order_direction=DESC&order_field=latest_disclosable_activity_at&followed_only=false&collaboration_only=false https://hackerone.com/hacktivity?querystring=graphql&filter=...
- valenterry 3y ago

dan-robertson 3y ago

I feel like this is a bad take: I’m not sure what your experience with graphql is but your comments about Netflix strike me as naive. I think there is a simplified version of Netflix that doesn’t do eg recommendation or history or different contracts in different countries and so on, which is maybe just a few api calls, but I don’t think that’s what Netflix is. And are they actually reinventing the wheel here? I thought graphql was a Facebook thing. Maybe you meant to say that they are rewriting systems pointlessly but it (also) feels like a bit of a generic criticism that is easy to apply to companies for which in-house systems make sense. (Edit: it’s not even like this is a graphql vs rest change as Netflix have had graphql for years and they have a custom api system that seems a lot more like graphql than it does rest) I’m curious what you think the best advantages of graphql are, particularly for a larger company like Netflix? I would guess: - reduces coordination/contention between different frontend/backend teams (eg there are many clients – desktop, mobile, various smart devices – but maybe other front ends too like something customer support might use). - cuts down on ‘boilerplate’ api work. For example, maybe you have some property X of each item Y in your catalog, but which you don’t get on the request for the catalog, and that you want to display this now (maybe it’s some new experimental feature you need to thread through from some database table to the front end). You need to choose between adding X to the catalog (potential version woes…) or managing a bunch of requests for X for each Y (risks being slow or bad in a few ways), or add some non-restful api endpoint that takes a list of Ys and gives you their X properties. With graphql you need to teach the backend how to get X of Y but the frontend only needs to change the query. - it potentially lets you apply access controls in a more straightforward way. If someone is from the US, maybe there are some shows they can’t see. In that case we probably want to hide all records in results about shows they can’t see. (Alternative example: various properties of other people’s accounts). If you have many separate api endpoints, it feels easier to me to accidentally screw up on one of them. I’m not really very familiar with graphql but the middle option is the most compelling one for some of the things I work on (which are nothing like Netflix). One assumes that some people from Netflix had reasons for graphql and I’m interested in what they were rather than some imagined Venn diagram with the current api in the ‘not invented here’ area and graphql in the intersection of ‘invented here’ and ‘not yet a thing we have’. I’d also be curious to see how well it works out for them over time – perhaps they’ll regret it but maybe not for the reasons you oppose graphql; if there are organisational problems (like some team becoming a big new bottleneck or some teams being unhappy about it being ‘forced on them’), they can be hard to write about.

pmoriarty 3y ago

GraphQL is such complete and utter garbage for anything but the simplest of queries. I pity anyone who has to use it for anything more complicated.

x86x87 3y ago
i would not go as far as saying complete and utter garbage, but it 95% of cases it brings with it a can of worms that you don't need and don't want. All in the name of "frontend developer velocity"!

8note 3y ago

How does http2 skip the speed of light to speed up sequential requests? Isn't the back and forth across the network the big problem?

x86x87 3y ago
In the beforefore time, you would need to establish a connection for every request you did if you wanted to make multiple requests in parallel and you were limited by how many request yoi could have in flight in parallel. With http2 you can mux the requests together through the same pipe. Yes, if you need to retrieve A to figure out you need B, it's not going to be "faster" but you would do the same thing on the server side. Also, for a well architected backend you can spread load better on the backend and shockingly you can also leverage caching if you are doing a "dumb" rest api.
- zeroonetwothree 3y ago
  GraphQL makes it straightforward to do conditional queries like: … on Book { title author if_viewer_can_purchase { price shipping } } This is quite annoying to do with traditional REST without overfetching data you don’t need.

xwowsersx 3y ago

Kong seems to have some offerings on the API gateway security front for GraphQL https://konghq.com/blog/engineering/graphql-authorization-at-the-api-gateway-with-kong-konnect-and-opa https://konghq.com/blog/engineering/graphql-authorization-at... I haven't looked at it very closely yet, but I'm wondering Kong for other reasons (unrelated to GQL)

thrashh 3y ago

GraphQL is like SQL. It’s an extremely leaky abstraction but in the hands of someone experienced, you can do amazing things with a fraction of the effort required. But just like SQL, you have people who happened to learn SQL in passing and it’s like a table saw in the hands of someone who doesn’t know what to do.

Humphrey 3y ago

Both REST and GraphQL API's can be well designed, or badly designed. While I'm a GraphQL fanboy, I would much prefer integrating with a well design REST API over a badly designed GraphQL API. Having spent over 15 years integrating with, and writing API's, GraphQL was a breath of fresh air! If you think of GraphQL as a query language, you will find it frustrating. If you think of it like you do a REST API with all the ugly pain points straightened out and standardised, then it is a dream to work with. GraphQL is as much of a query language as REST is. For example, most REST API's end up getting super long lists of parameters in their urls. How many eCommerce API's end up having REST URL's like: /api/products?category=guitars&include_variants=true&page=20&per_page=100&exclude_fields=description,specs Whereas, GraphQL transforms that into a simple, readable query, which does not require reading pages and pages of documentation to understand. But, if you are creating well designed REST API's, I would prefer to use them over somebodies poorly written Graph. Just like a REST API, a well written Graph should be crafted to be fast and performant to execute. Just like with REST, a Graph designer needs to sit down and think about the ways people will want to use the API. A good graph does not allow endless relationships that will cause performance to blow out.

rapsey 3y ago
/api/products?category=guitars&include_variants=true&page=20&per_page=100&exclude_fields=description,specs Seems pretty readable to me.
- anytime5704 3y ago
  Also, url query parameters are kind of orthogonal to REST vs. GQL. They can complement either API. From personal experience, choosing not to use them (as most single page web apps don’t) can make testing painful and makes deep-linking to specific states of your webpage impossible.
argentier 3y ago
> GraphQL is as much of a query language as REST is This doesn't make any sense, unless it's to point out that GraphQL is not a query language at all.

insanitybit 3y ago

> Also, in general being able to say "i want to do whatever" and request everything at once is an anti-pattern IMHO, especially after HTTP2 became mainstream and doing multiple requests is reasonably fast. It's not about performance, it's about being able to trivially get the data you need in one request and get it back in a way that you've structured.

baka367 3y ago

For us the primary value is behind the customizability of it all. One of our main requirements is to give user A LOT of flexibility to customize the default frontend to suit their needs. On top of that we are running DDD in the backend with ARs being spread over multiple different services. We did experiment with rest early on, but we found out that we would need to make our frontned to be extremely complicated and vocal to handle the customization/data fetching requirements or build our own REST gateway on top of open API, doing, essentially, the same thing that graphql gateway does out of the box. Adopting graphql was scary at first with low team exposure to the technology, but using REST would have made our life much much harder

IceDane 3y ago

This rhetoric pops up every time gql is discussed on HN, and it is invariably full of misconceptions and, well, nonsense, that just tells anyone who's actually used gql that you clearly haven't. I never understood why people insist on having strong opinions on things they clearly know nothing about.

PaulHoule 3y ago

People are drawn like moths to a flame to anything that is poorly specified and are repelled by the well-defined. A visit to the ontologist is feared somewhere between a visit to the oncologist and the orthodontist. To be fair, GraphQL has a real specification now but it didn’t back when it was taking off like wildfire.

fbjork 3y ago

GraphQL really shines when it comes to providing a unified data layer for frontend teams. Having a consistent, typed API is a big time saver for developers building data rich applications. The ability for frontend teams to shape the data they need without talking to a backend developer and reduce the number of requests made to the API makes for a perfect match when building high performance applications.