9 ms·

Never understood the hype around GraphQL. You want to know how to halve your performance and responses/s on your service? add graphql. All things that GraphQL

Never understood the hype around GraphQL. You want to know how to halve your performance and responses/s on your service? add graphql. All things that GraphQL claims to do can be implemented in RESTful services easily. If you want specificity in your query fetching, just add query params or put them in the request body If you want schema validations, there are many libraries that help you with that. And if you want data from multiple resources from different endpoints, what exactly is stopping you from implementing that in REST? Also, GraphQL has a steeper learning curve as opposed to REST. never understood graphql. To me its just an abstract layer between the front end and back end, adding to the already complex stack.

n_e 6y ago
> All things that GraphQL claims to do can be implemented in RESTful services easily. How do you easily write an endpoint that can either return a comment, a comment with its children, a comment with its corresponding story, with a strongly typed schema (ie. no optional children or story whatever the query is)?
- fc373745 6y ago
  like i said, specify what you want in the query params or in the request body
  - dnautics 6y ago
    So, what you are saying is reimplement graphQL.
    - fc373745 6y ago
      no, what im saying is graphql is introducing something they think is novel, when it already can be done in REST. it's not hard. In my specific case, using Flask-Marshmallow i can do this ``` some_resource = Resource.find_by_id(resource_id) arg = request.args.get('type_of_resource') if arg == 'with_commments': return full_resource_schema.dump(some_resource), 200 if arg == 'no_comments': return no_comments_schema.dump(some_resource), 200 ``` there i just implemented graphql in 6 lines of code
      - dnautics 6y ago
        The whole point of graphQL is to allow FE teams to decide what information they need in an organizationally decoupled fashion, you haven't done that at all. Suppose FE wants another join on that object, now they must wait for you to push more code enabling those queries.
        fc373745 6y ago
        Unfortunately for graphql, the claim that backend teams need to be constantly making endpoints for other decoupled teams is not as drastic and critical as you consider it to be. Dare i even say switching to graphql and onboarding developers to graphql is a much more resource intensive process than adding another endpoint (or a couple).
        dnautics 6y ago
        > onboarding developers to graphql is a much more resource intensive process As a BE/remote I basically taught myself most of elixir's graphQL framework in a day (wait, that was yesterday), while under feature pressure (due this afternoon), mostly by poking around and doing a bit of TDD. There are parts that I really hate about graphQL, but overall I consider it a win.
        simiones 6y ago
        The problem with GraphQL is on the front end. Suddenly, the FE team becomes responsible for understanding the entire data model, which resources can be joined together, by what keys, and what is actually performant vs what isn't. Instead of doing a simple GET /a/b/1/c and presenting that data structure, they now need to define a query, think about what resources to pull into that query etc. If the query ends up being slow, they have to understand why and work on more complex changes than simply asking the BE team for a smaller response with a few query params.
        dnautics 6y ago
throwoutttt 6y ago
For comprehensive APIs,GraphQL is often more performant. 1 request that takes 500ms is far better to 5 requests that take 200ms
- systemvoltage 6y ago
  You can create a single endpoint that's non-RESTFul to make a single call.
  - adamscybot 6y ago
    Yes and by doing so you lost the advantages of a predictable and well organised API. GraphQL has first class support for this scenario.
    - systemvoltage 6y ago
      I disagree. You're shifting your "organization" to the frontend which becomes an utter cesspool of chaos. If anything changes in the backend, you will need to change the frontend as well. The whole point of an API is to decouple. GraphQL does the exact opposite.
- cunac 6y ago
  depends, if all requests are parallel they should hit different instances and that would distribute load more efficiently instead of pinning to single instance. You would actually get response in 200ms not to mention that your ability to properly size each node is increased. It also enables you to have a grey area where response can be partial and not just fail/pass. As usual YMMW depending on use case.
patrickcteng 6y ago
I love this comment so much. With GraphQL, you're just pushing N+1 calls and figuring out the mental contortion needed to support all the graphy-ness from non-graph structures. Most that say GraphQL is the bees-knees must be an FE developer. There's nothing wrong with that, but GraphQL is just NOT as cracked up to be.
- pier25 6y ago
  I'm not a GraphQL advocate and barely use it myself, but the N+1 problem has been solved in many server implementations. Eg: Hasura. https://hasura.io/blog/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87/ https://hasura.io/blog/architecture-of-a-high-performance-gr...
gengstrand 6y ago
I also wanted to understand why GQL was getting so much attention in a REST vs GraphQL way so I implemented a GQL microservice that had the same features as a service that I had implemented previously as REST. Both services ran on node.js and connected to the same data stores, etc. I ran both services on the same load test lab and documented my findings at https://glennengstrand.info/software/architecture/microservice/graphql https://glennengstrand.info/software/architecture/microservi... The TL;DR of that blog is this. There isn't much value that GQL can provide over REST + OpenAPI. GQL is still in its infancy so APM is easier with REST. The biggest argument for GQL is returning the right amount of data but GQL is slightly slower than REST because the server is having to parse what is essentially a mini program with every request.
- adamscybot 6y ago
  If you're a front end developer the advantages a clear because of much superior tooling. The reason for this the agreed SDL spec format which is part and parcel of GQL. REST is just a loose collection of ideas and OpenAPI is not integral to REST as theres no single over arching spec of organisation for REST. In my experence therefore, the tooing (code gen, doc gen) etc around OpenAPI is piss poor in comparison to gql. Just look at GraphIQL compared to postman.
  - gengstrand 6y ago
    The above referenced PoC service based on express uses https://github.com/apigee-127/swagger-tools https://github.com/apigee-127/swagger-tools which surfaces a web app by which front end devs navigate through the published API endpoints. They can use the web app to call the service via the endpoint or copy and paste sample code that calls the service. Most open api integrations support this kind of functionality.
  - simiones 6y ago
    From my experience, front-end developers are the last people that want to learn how to query a complex data model. It's usually much preferable if the backend team exposes the required endpoints for any UI operation, since they have much more fine-grained control on the DB and a much clearer intuition on what is easy to do and what isn't.
jrockway 6y ago
I think people like it because the popular frontend library (Apollo) makes certain things easy in React, like caching. From a backend perspective, it's about 100x more work than dumb RPC (which I prefer over "REST"). I have spent so much time becoming aware of very "interesting" decisions. For example, gqlgen for Go generates code that fetches every element of a slice in parallel. We used to create one database transaction per HTTP request, but you can't do this with GraphQL, because it fetches each row of the database in a separate goroutine, and that is not something you can do with database transactions. It's also exceedingly inefficient. All in all, it's clear to me that GraphQL is built with the mindset that you are reaching out to an external service to fetch every piece of data. That makes a lot of sense in certain use cases, but makes less sense if you are just building a CRUD app that talks to a single database. I am hoping that people get bored with this and make gRPC/Web not require a terabyte of Javascript to be sent to the client. RPCs are so easy. Call a function with an argument. Receive a return value and status code. Easy. Boring. It's perfect.
adamscybot 6y ago
One thing people havent mentioned as well is the importance of mutations. Querying is only one side of the story. Your API should match semantic actions on your client like the UI and it needs to do this in such a way that it happens in one database transaction. With REST, new UI requirement that needs to save 2 objects together across multiple entity types...? GG.

n_e 6y ago

> All things that GraphQL claims to do can be implemented in RESTful services easily. How do you easily write an endpoint that can either return a comment, a comment with its children, a comment with its corresponding story, with a strongly typed schema (ie. no optional children or story whatever the query is)?

fc373745 6y ago
like i said, specify what you want in the query params or in the request body
- dnautics 6y ago
  So, what you are saying is reimplement graphQL.
  - fc373745 6y ago
    no, what im saying is graphql is introducing something they think is novel, when it already can be done in REST. it's not hard. In my specific case, using Flask-Marshmallow i can do this ``` some_resource = Resource.find_by_id(resource_id) arg = request.args.get('type_of_resource') if arg == 'with_commments': return full_resource_schema.dump(some_resource), 200 if arg == 'no_comments': return no_comments_schema.dump(some_resource), 200 ``` there i just implemented graphql in 6 lines of code
    - dnautics 6y ago
      The whole point of graphQL is to allow FE teams to decide what information they need in an organizationally decoupled fashion, you haven't done that at all. Suppose FE wants another join on that object, now they must wait for you to push more code enabling those queries.
      - fc373745 6y ago
        Unfortunately for graphql, the claim that backend teams need to be constantly making endpoints for other decoupled teams is not as drastic and critical as you consider it to be. Dare i even say switching to graphql and onboarding developers to graphql is a much more resource intensive process than adding another endpoint (or a couple).
        dnautics 6y ago
        > onboarding developers to graphql is a much more resource intensive process As a BE/remote I basically taught myself most of elixir's graphQL framework in a day (wait, that was yesterday), while under feature pressure (due this afternoon), mostly by poking around and doing a bit of TDD. There are parts that I really hate about graphQL, but overall I consider it a win.
        simiones 6y ago
        The problem with GraphQL is on the front end. Suddenly, the FE team becomes responsible for understanding the entire data model, which resources can be joined together, by what keys, and what is actually performant vs what isn't. Instead of doing a simple GET /a/b/1/c and presenting that data structure, they now need to define a query, think about what resources to pull into that query etc. If the query ends up being slow, they have to understand why and work on more complex changes than simply asking the BE team for a smaller response with a few query params.
        dnautics 6y ago

throwoutttt 6y ago

For comprehensive APIs,GraphQL is often more performant. 1 request that takes 500ms is far better to 5 requests that take 200ms

systemvoltage 6y ago
You can create a single endpoint that's non-RESTFul to make a single call.
- adamscybot 6y ago
  Yes and by doing so you lost the advantages of a predictable and well organised API. GraphQL has first class support for this scenario.
  - systemvoltage 6y ago
    I disagree. You're shifting your "organization" to the frontend which becomes an utter cesspool of chaos. If anything changes in the backend, you will need to change the frontend as well. The whole point of an API is to decouple. GraphQL does the exact opposite.
cunac 6y ago
depends, if all requests are parallel they should hit different instances and that would distribute load more efficiently instead of pinning to single instance. You would actually get response in 200ms not to mention that your ability to properly size each node is increased. It also enables you to have a grey area where response can be partial and not just fail/pass. As usual YMMW depending on use case.

patrickcteng 6y ago

I love this comment so much. With GraphQL, you're just pushing N+1 calls and figuring out the mental contortion needed to support all the graphy-ness from non-graph structures. Most that say GraphQL is the bees-knees must be an FE developer. There's nothing wrong with that, but GraphQL is just NOT as cracked up to be.

pier25 6y ago
I'm not a GraphQL advocate and barely use it myself, but the N+1 problem has been solved in many server implementations. Eg: Hasura. https://hasura.io/blog/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87/ https://hasura.io/blog/architecture-of-a-high-performance-gr...

gengstrand 6y ago

I also wanted to understand why GQL was getting so much attention in a REST vs GraphQL way so I implemented a GQL microservice that had the same features as a service that I had implemented previously as REST. Both services ran on node.js and connected to the same data stores, etc. I ran both services on the same load test lab and documented my findings at https://glennengstrand.info/software/architecture/microservice/graphql https://glennengstrand.info/software/architecture/microservi... The TL;DR of that blog is this. There isn't much value that GQL can provide over REST + OpenAPI. GQL is still in its infancy so APM is easier with REST. The biggest argument for GQL is returning the right amount of data but GQL is slightly slower than REST because the server is having to parse what is essentially a mini program with every request.

adamscybot 6y ago
If you're a front end developer the advantages a clear because of much superior tooling. The reason for this the agreed SDL spec format which is part and parcel of GQL. REST is just a loose collection of ideas and OpenAPI is not integral to REST as theres no single over arching spec of organisation for REST. In my experence therefore, the tooing (code gen, doc gen) etc around OpenAPI is piss poor in comparison to gql. Just look at GraphIQL compared to postman.
- gengstrand 6y ago
  The above referenced PoC service based on express uses https://github.com/apigee-127/swagger-tools https://github.com/apigee-127/swagger-tools which surfaces a web app by which front end devs navigate through the published API endpoints. They can use the web app to call the service via the endpoint or copy and paste sample code that calls the service. Most open api integrations support this kind of functionality.
- simiones 6y ago
  From my experience, front-end developers are the last people that want to learn how to query a complex data model. It's usually much preferable if the backend team exposes the required endpoints for any UI operation, since they have much more fine-grained control on the DB and a much clearer intuition on what is easy to do and what isn't.

jrockway 6y ago

I think people like it because the popular frontend library (Apollo) makes certain things easy in React, like caching. From a backend perspective, it's about 100x more work than dumb RPC (which I prefer over "REST"). I have spent so much time becoming aware of very "interesting" decisions. For example, gqlgen for Go generates code that fetches every element of a slice in parallel. We used to create one database transaction per HTTP request, but you can't do this with GraphQL, because it fetches each row of the database in a separate goroutine, and that is not something you can do with database transactions. It's also exceedingly inefficient. All in all, it's clear to me that GraphQL is built with the mindset that you are reaching out to an external service to fetch every piece of data. That makes a lot of sense in certain use cases, but makes less sense if you are just building a CRUD app that talks to a single database. I am hoping that people get bored with this and make gRPC/Web not require a terabyte of Javascript to be sent to the client. RPCs are so easy. Call a function with an argument. Receive a return value and status code. Easy. Boring. It's perfect.

adamscybot 6y ago

One thing people havent mentioned as well is the importance of mutations. Querying is only one side of the story. Your API should match semantic actions on your client like the UI and it needs to do this in such a way that it happens in one database transaction. With REST, new UI requirement that needs to save 2 objects together across multiple entity types...? GG.