3 ms·

I’ve been in GraphQL land for 4-5 years now, and all these discussions about restfulness, Http and other details make me cringe. It feels like watching apes fi

I’ve been in GraphQL land for 4-5 years now, and all these discussions about restfulness, Http and other details make me cringe. It feels like watching apes fighting about whether the cylinder goes in the triangle or star-shaped hole. It does not fit! Realize this and move on! Unless your company is only about CRUD (with no JOINs), the Rest model is severely limited or mismatched to your business domain. Just use GraphQL already. It’s actually simple, I promise! Self documenting, introspectable, supports so much code generation and validation tools, etc... I know I’ll get downvoted for saying this, the HN crowd thinks « GraphQL = complicated » for some reason.

jpdb 5y ago
I've liked GraphQL the few times I've used it, but I think the standard way of doing pagination with `node`s and `edge`s makes me feel less like I'm working with my data and more some odd abstraction. I think if I used GraphQL more I could get over it, but that aspect always makes me wish for just a bit more.
- crubier 5y ago
  What you are talking about is the Relay specification, not GraphQL. Relay is completely optional and only a way to optimize performance of client side stuff. Here is how you deal with lists in normal GraphQL: type Query { projects(first: Int): [Project!]! } type Project { id: Int name: String }
andrewmcwatters 5y ago
GraphQL is inherently more complicated. It's one more step at a minimum, and more honestly two or three more steps. I can build an endpoint and point it straight to a parameterized SQL query. With GraphQL, I build an endpoint, and point it straight to a GraphQL... schema? And then I have to define where that data comes from, and then how to return it... It's just professional negligence to suggest it's not more involved.
- crubier 5y ago
  The 15 seconds and 10 lines of code you "loose" defining your graphQL schema saves you hours soon after, when you'll be fixing the problems created by poorly structured REST endpoint and endless debates. With REST: I can build an endpoint and point it straight to a parameterized SQL query. With GraphQL: I can build a resolver and point it straight to a parameterized SQL query. So yes, I insist that it's overall much simpler to use GraphQL, having done both extensively. Here is a GraphQL server in Python, (Note that it automatically provides documentation, a GraphQL interactive playground, Introspection, etc.). Do the same with Rest and tell me where the overhead is from ariadne import QueryType, make_executable_schema from ariadne.asgi import GraphQL from starlette.applications import Starlette type_defs = """ type Query { projects(first: Int): [Project!]! } type Project { id: Int name: String } """ query = QueryType() @query.field("projects") async def resolve_projects(_, info, first=10): query = projects.select().limit(first) results = await database.fetch_all(query) return results Starlette().mount( "/graphql", GraphQL(make_executable_schema(type_defs, query)), ) (It could be made even shorter with Graphene, but shorter != better in my opinion).

jpdb 5y ago

I've liked GraphQL the few times I've used it, but I think the standard way of doing pagination with `node`s and `edge`s makes me feel less like I'm working with my data and more some odd abstraction. I think if I used GraphQL more I could get over it, but that aspect always makes me wish for just a bit more.

crubier 5y ago
What you are talking about is the Relay specification, not GraphQL. Relay is completely optional and only a way to optimize performance of client side stuff. Here is how you deal with lists in normal GraphQL: type Query { projects(first: Int): [Project!]! } type Project { id: Int name: String }

andrewmcwatters 5y ago

GraphQL is inherently more complicated. It's one more step at a minimum, and more honestly two or three more steps. I can build an endpoint and point it straight to a parameterized SQL query. With GraphQL, I build an endpoint, and point it straight to a GraphQL... schema? And then I have to define where that data comes from, and then how to return it... It's just professional negligence to suggest it's not more involved.

crubier 5y ago
The 15 seconds and 10 lines of code you "loose" defining your graphQL schema saves you hours soon after, when you'll be fixing the problems created by poorly structured REST endpoint and endless debates. With REST: I can build an endpoint and point it straight to a parameterized SQL query. With GraphQL: I can build a resolver and point it straight to a parameterized SQL query. So yes, I insist that it's overall much simpler to use GraphQL, having done both extensively. Here is a GraphQL server in Python, (Note that it automatically provides documentation, a GraphQL interactive playground, Introspection, etc.). Do the same with Rest and tell me where the overhead is from ariadne import QueryType, make_executable_schema from ariadne.asgi import GraphQL from starlette.applications import Starlette type_defs = """ type Query { projects(first: Int): [Project!]! } type Project { id: Int name: String } """ query = QueryType() @query.field("projects") async def resolve_projects(_, info, first=10): query = projects.select().limit(first) results = await database.fetch_all(query) return results Starlette().mount( "/graphql", GraphQL(make_executable_schema(type_defs, query)), ) (It could be made even shorter with Graphene, but shorter != better in my opinion).