3 ms·

My experience trying to build out the server side backend in GraphQL for various features was miserable: * you are adding an additional abstraction layer on to

My experience trying to build out the server side backend in GraphQL for various features was miserable: * you are adding an additional abstraction layer on top of your data store (in our case, SQL), with significant cost in complexity and speed. This was for queries that served many thousands (or more) of requests a day, btw, so maybe it would be fine for apps w/ just tens or hundreds of users. * trying to get any complex queries performant was _very_ difficult. We knew how to avoid n+1's w/ SQL and our ORM, but doing so with GraphQL loaders was very difficult and required some very intense promise-based code that was incredibly hard to debug or understand. * the abstractions felt all wrong - it often felt like our the GraphQL loading layer was completely disjoint from the existing domain model. Building out the GraphQL layer often came at the expense of the domain layer -- maybe this was due to our own inexperience in mixing the two ? Anyway, it felt similar to how impossible it felt to build a decent domain model back in the days of Javabean / EJB frameworks. That was my experience around a year or year and a half ago, anyways. I definitely see the value in the declarative nature of GraphQL for client usage, but the cost on the server side felt _very high_ to make it a reality.

chrisco255 9y ago
I didn't have that experience. Plus you can always have both REST and GraphQL. Your GraphQL server can simply call your REST endpoints. If you already have a REST API built it's not that much work to set up a GraphQL gateway.
faitswulff 9y ago
I've heard GraphQL is a better match for graph databases. I wonder if the issues you encountered might be a result of that mismatch?
- joshribakoff 9y ago
  Not true per se, the name GraphQL is you are conceptually thinking about your data in terms of a graph. The underlying data store could be parsing a CSV file to resolve your data & graphQL still adds immense value.
ruslan_talpa 9y ago
It’s miserable when your starting point is the default js implementation for the executor, but if you write your own executor you have a lot of freedom to do cool stuff. I’ve built a graphql interface here https://subzero.cloud https://subzero.cloud on top of the powerful rest interface of https://postgrest.com https://postgrest.com which in turn sits on top of postgresql. The end result is you define your tables/views/functions in sql and on the other end you get rest+graphql api to your data
joshribakoff 9y ago
> We knew how to avoid n+1's w/ SQL You can simply create one graphQL field corresponding to each REST end point you have now, and have it do an SQL query in the resolver. > you are adding an additional abstraction layer on top of your data store yes that is one of the main benefits (it allows you to coalesce data from multiple data stores).

chrisco255 9y ago

I didn't have that experience. Plus you can always have both REST and GraphQL. Your GraphQL server can simply call your REST endpoints. If you already have a REST API built it's not that much work to set up a GraphQL gateway.

faitswulff 9y ago

I've heard GraphQL is a better match for graph databases. I wonder if the issues you encountered might be a result of that mismatch?

joshribakoff 9y ago
Not true per se, the name GraphQL is you are conceptually thinking about your data in terms of a graph. The underlying data store could be parsing a CSV file to resolve your data & graphQL still adds immense value.

ruslan_talpa 9y ago

It’s miserable when your starting point is the default js implementation for the executor, but if you write your own executor you have a lot of freedom to do cool stuff. I’ve built a graphql interface here https://subzero.cloud https://subzero.cloud on top of the powerful rest interface of https://postgrest.com https://postgrest.com which in turn sits on top of postgresql. The end result is you define your tables/views/functions in sql and on the other end you get rest+graphql api to your data

joshribakoff 9y ago

> We knew how to avoid n+1's w/ SQL You can simply create one graphQL field corresponding to each REST end point you have now, and have it do an SQL query in the resolver. > you are adding an additional abstraction layer on top of your data store yes that is one of the main benefits (it allows you to coalesce data from multiple data stores).