4 ms·

As a front end developer my life is much less complex with GraphQL, especially with TypeScript in React. I'm curious, what tasks do you find more complex?

by dmalik 5y ago

adeptima 5y ago
Advanced "Left Join" query building similar to Crunchbase search https://www.crunchbase.com/search/ https://www.crunchbase.com/search/ ... with lot of deep LEFT JOIN behind. Opted out for Golang with REST after prototyping with GraphQL
- cpursley 5y ago
  I'm able to do super complex joins with Postgres views and Hasura or Absinthe (Elixir Phoenix). YMMV.
sillyquiet 5y ago
This is my experience too. A negotiated schema + Typescript means many fewer bugs due to unexpected data shapes. Also error conditions are much more understandable. Also, GraphQL is not a replacement for REST... I am not sure why people keep making this equivalency.
- dragonwriter 5y ago
  > Also, GraphQL is not a replacement for REST... I am not sure why people keep making this equivalency. GraphQL is arguably consistent with actual REST, but its a replacement for trivial JSON CRUD over HTTP, which is one of the common abuses of the term “REST”.
  - collyw 5y ago
    I thought everything went over a Post requests and returned 200 error codes whatever. Doesn't sound like REST to me.
    - quonn 5y ago
      I agree, it‘s certainly not REST. It does not have to be a POST request or even HTTP. The point about the 200 status code is correct.
    - sillyquiet 5y ago
      A REST-ful POST is a pretty standard implementation of a graphQL network call yeah - it's subject to the same limitations and error handling as any other request. The confusion comes in when are talking about what happens at on the graphQL server and the calls it makes. Say for example your browser code makes a single graphQL query to a graphQL endpoint - that server in turn can generate multiple REST-full service calls, file reads, in-memory cache retrievals or whatever to fulfill the graphQL schema as determined by the incoming graphQL query. All that was initiated by a single graphQL query (a single POST) from the client. What do you report back to the client if one out of the three server-side REST calls fails? Depending the schema, your initial query is still successful, it's just that one of the fields is empty or NULL (again depending on the schema). So that by any reasonable definition is still a 200. Even if all service calls failed, if your schema allows for fields to be empty or NULL, it can still be considered successful. All that is to say that graphQL is not a replacement for REST, it's an enhancement that serves as a negotiable schema between client and service, a data orchestration layer that can stitch together multiple data sources into that schema, and as a pretty robust way to think about what to present to the user in error conditions since every field you want in your query, presumably, serves in the UI in some way. It gives you the tools to intelligently handle when those fields are not available. You can do that with vanilla REST calls of course and roll your own solutions to the problems graphQL solves (or tries to solve).
      - collyw 5y ago
        > Say for example your browser code makes a single graphQL query to a graphQL endpoint - that server in turn can generate multiple REST-full service calls, file reads, in-memory cache retrievals or whatever to fulfill the graphQL schema as determined by the incoming graphQL query. I can do that in any Django view, REST or otherwise. How is that unique to Graphql? I really can't see what I gain. You define your response in Swagger or you do it in Graphql.
SketchySeaBeast 5y ago
In the implementation of GraphQL I work with I find that I end up making giant string mutations/queries that I can't use any sort of intellisense for - it's just guessing and checking with running the queries. Is there a better way to get more than passing back a really long string?
- dtech 5y ago
  I use IntelliJ, in our setup it gives complete checking and autocomplete. YMMV It sounds to me like you could benefit from some kind of codegen [1] to generate native language code out of graphql and checking the queries at compile/build-time instead of runtime. GraphQL playground [2] might be a lower-investment tool to help you. [1] In JS/TS GraphQL code generator is the standard: https://www.graphql-code-generator.com/ https://www.graphql-code-generator.com/ Other languages have similar tools. [2] https://github.com/graphql/graphql-playground https://github.com/graphql/graphql-playground
- quonn 5y ago
  On the client, use the gql tag, a GraphQL code generator to generate TypeScript types from the gql tagged queries and the appropriate editor/linter tooling. Then everything is checked when building or directly in the editor.
pier25 5y ago
As a front end developer you're only seeing half of the picture.

As a front end developer my life is much less complex with GraphQL, especially with TypeScript in React. I'm curious, what tasks do you find more complex?

by dmalik 5y ago

As a front end developer my life is much less complex with GraphQL, especially with TypeScript in React. I'm curious, what tasks do you find more complex?

adeptima 5y ago

Advanced "Left Join" query building similar to Crunchbase search https://www.crunchbase.com/search/ https://www.crunchbase.com/search/ ... with lot of deep LEFT JOIN behind. Opted out for Golang with REST after prototyping with GraphQL

cpursley 5y ago
I'm able to do super complex joins with Postgres views and Hasura or Absinthe (Elixir Phoenix). YMMV.

sillyquiet 5y ago

This is my experience too. A negotiated schema + Typescript means many fewer bugs due to unexpected data shapes. Also error conditions are much more understandable. Also, GraphQL is not a replacement for REST... I am not sure why people keep making this equivalency.

dragonwriter 5y ago
> Also, GraphQL is not a replacement for REST... I am not sure why people keep making this equivalency. GraphQL is arguably consistent with actual REST, but its a replacement for trivial JSON CRUD over HTTP, which is one of the common abuses of the term “REST”.
- collyw 5y ago
  I thought everything went over a Post requests and returned 200 error codes whatever. Doesn't sound like REST to me.
  - quonn 5y ago
    I agree, it‘s certainly not REST. It does not have to be a POST request or even HTTP. The point about the 200 status code is correct.
  - sillyquiet 5y ago
    A REST-ful POST is a pretty standard implementation of a graphQL network call yeah - it's subject to the same limitations and error handling as any other request. The confusion comes in when are talking about what happens at on the graphQL server and the calls it makes. Say for example your browser code makes a single graphQL query to a graphQL endpoint - that server in turn can generate multiple REST-full service calls, file reads, in-memory cache retrievals or whatever to fulfill the graphQL schema as determined by the incoming graphQL query. All that was initiated by a single graphQL query (a single POST) from the client. What do you report back to the client if one out of the three server-side REST calls fails? Depending the schema, your initial query is still successful, it's just that one of the fields is empty or NULL (again depending on the schema). So that by any reasonable definition is still a 200. Even if all service calls failed, if your schema allows for fields to be empty or NULL, it can still be considered successful. All that is to say that graphQL is not a replacement for REST, it's an enhancement that serves as a negotiable schema between client and service, a data orchestration layer that can stitch together multiple data sources into that schema, and as a pretty robust way to think about what to present to the user in error conditions since every field you want in your query, presumably, serves in the UI in some way. It gives you the tools to intelligently handle when those fields are not available. You can do that with vanilla REST calls of course and roll your own solutions to the problems graphQL solves (or tries to solve).
    - collyw 5y ago
      > Say for example your browser code makes a single graphQL query to a graphQL endpoint - that server in turn can generate multiple REST-full service calls, file reads, in-memory cache retrievals or whatever to fulfill the graphQL schema as determined by the incoming graphQL query. I can do that in any Django view, REST or otherwise. How is that unique to Graphql? I really can't see what I gain. You define your response in Swagger or you do it in Graphql.

SketchySeaBeast 5y ago

In the implementation of GraphQL I work with I find that I end up making giant string mutations/queries that I can't use any sort of intellisense for - it's just guessing and checking with running the queries. Is there a better way to get more than passing back a really long string?

dtech 5y ago
I use IntelliJ, in our setup it gives complete checking and autocomplete. YMMV It sounds to me like you could benefit from some kind of codegen [1] to generate native language code out of graphql and checking the queries at compile/build-time instead of runtime. GraphQL playground [2] might be a lower-investment tool to help you. [1] In JS/TS GraphQL code generator is the standard: https://www.graphql-code-generator.com/ https://www.graphql-code-generator.com/ Other languages have similar tools. [2] https://github.com/graphql/graphql-playground https://github.com/graphql/graphql-playground
quonn 5y ago
On the client, use the gql tag, a GraphQL code generator to generate TypeScript types from the gql tagged queries and the appropriate editor/linter tooling. Then everything is checked when building or directly in the editor.

pier25 5y ago

As a front end developer you're only seeing half of the picture.