7 ms·

Another week, another submission that hopefully edges more people towards realizing that they've just created an under-standardized, under-powered SQL-with-braa

Another week, another submission that hopefully edges more people towards realizing that they've just created an under-standardized, under-powered SQL-with-braackets that forces you to bring your own query optimizer, and eschews the advancements of Swagger/OpenAPI, JSONSchema, HAL, JSON-LD and the flexibility of HATEOAS. All for a little bit of a velocity gain from declarative syntax and horizontal/vertical filtering. This code is probably very useful to the people who made it and those in the GraphQL+Swift ecosystem, but we were already here (and just starting to get drastically better) with OpenAPI -- it's not like all the effort is only going in one direction but GraphQL really feels like a less-than-optimal branch. The final piece of the puzzle for me will be when someone starts to replace the dynamic properties of the more advanced REST-ful techniques (API discovery, link following, etc) in GraphQL. Then the circle will be complete -- we'll have rebuilt XML (in the "linked data" respect anyway, not so much the accidental complexity side) and it's related standards twice in under ~20 years.

rand_r 6y ago
Does OpenAPI have a way for the client to whitelist fields? I see that as a major selling point for GraphQL. Without it, you end up having to create tailored endpoints for each use-case vs. for example a single “user” endpoint/vertex that supports the complete buffet of fields for all use-cases in one convenient place.
- hardwaresofton 6y ago
  I can't say that it should have that feature -- I'd say that is outside the purview of OpenAPI itself, but it could definitely be built in in a repeatable and scalable way pretty simply. I can tell you that tools like PostgREST have had this for a long time[0]. [0]: https://postgrest.org/en/v7.0.0/api.html#vertical-filtering-columns https://postgrest.org/en/v7.0.0/api.html#vertical-filtering-...
mikecaulley 6y ago
I've found GraphQL to greatly improve the developer experience when building web apps. As a front-end developer you can easily get a full view of the data and relationships. Tools like GraphiQL make exploring APIs a pleasure. And regardless of what you need to present to the user on screen, you can quickly build a request that perfectly matches the data you need. There is also the nice addition of strict typing and there are libraries that automatically generate TypeScript types for you from the schema and/or your operations.
- jamil7 6y ago
  I don't have especially strong feelings either way, but the majority of this is possible with OpenAPI as well.
- kristaps 6y ago
  I would like a backend developer perspective on the same. I haven't done any GraphQL stuff myself, but the "I can get whatever data I need" aspect feels like a huge potential headache for backend devs. Won't be a problem at prototype scale, but once you have a significant client count, how do you deal with unpredictable data access patterns that can't be optimized ahead of time?
  - mikecaulley 6y ago
    Generally speaking, it's not more difficult than creating a REST API controller. Rather than mapping your service code to a controller, you map it to a (GraphQL) resolver. It feels extremely similar. There are different things to look out for; like handling n+1 (https://shopify.engineering/solving-the-n-1-problem-for-graphql-through-batching https://shopify.engineering/solving-the-n-1-problem-for-grap...) queries, but nothing that I can say is too difficult.
    - dmitriid 6y ago
      It is more difficult. With REST you know ahead of time which data you need, and you can optimise it as much as you can. With GraphQL at any given point in time you have no idea what the request is. Dataloaders solve it to some extent, but not much.
      - mikecaulley 6y ago
        Of course, you are building something that is much more powerful. If you intend every possible GraphQL operation to perform perfectly, it'll take more development effort. Though if you optimize for only the most likely cases, the effort is not much greater.
erikpukinskis 6y ago
I don’t really think of GraphQL as a data querying language like SQL. I think of it as a domain querying language. SQL is meant to allow you to write queries to your data model which are: - arbitrary, and - efficient I don’t think of GraphQL that way. I think of it as the place where you encode your set of valid domain actions (i.e. not arbitrary). And I don’t think the consumers of the GraphQL API should think about efficiency. They should just specify what data they need and then the backend is responsible for figuring out how to query the data model efficiently. In other words, I don’t really see any overlap between GraphQL and SQL in terms of the role they play in a stack. One helpful thing this distinction allows, is type inference. You can trivially write a type generator that gives you the type signature of a GraphQL query in any language. This is precisely because of its limitations. That allows you to automate the validation of your frontend and backend speaking the same language. You can’t easily infer the return types of arbitrary SQL queries. To me, that highlights the different purposes of the languages.
- codenesium 6y ago
  When your backend is sql how can you even do this efficiently? Databases require indexes. If you can query anything then there are performance bombs all over the place. It's different if you're querying elastic I guess.
  - jkrems 6y ago
    > If you can query anything [...] The answer is simple: You can't. GraphQL _in general_ doesn't allow arbitrary queries. It allows arbitrary output field selection. But the filters are very explicit. It's more "pre-aggregation of request waterfalls and masking of outputs" than "querying a database". Doesn't stop people from exposing their SQL databases directly from GraphQL by generating a "free-for-all" schema. And when they do - yep, that's definitely a performance bomb and not a good use of GraphQL.
    - dmitriid 6y ago
      > The answer is simple: You can't. GraphQL _in general_ doesn't allow arbitrary queries. It really does. Surely, it somewhat limits the data that you get from it by defining a schema. But the moment you allow any nesting/connections between data in that schema, hello n+1 problem. And then every discussion of this problem on HN or elsewhere exposes the ugly truth: almost everyone uses GraphQL as a REST endpoint in production by limiting the actual queries you can run and curbing nesting.
jkcxn 6y ago
> replace the dynamic properties of the more advanced REST-ful techniques (API discovery, link following, etc) in GraphQL Isn't this exactly what GraphQL does? I may be missing something
humbleMouse 6y ago
100% agree. People also need to remember that GraphQL was originally written for server side javascript, and now it’s being ported to other languages(for what reason???). You can create your own global json schema and build a ratchet version of GraphQL using proven orms in about 20 minutes using an unpersisted “filtering” field. If you want automatic access to your data, bite the bullet and do something cool like implement Apache Dremio.
- santialbo 6y ago
  GraphQL was released as an specification with a node example implementation. It wasn't "written for server side javascript".
  - humbleMouse 6y ago
    Ok, so it was software released with it’s first implementation written in node. And now have “Apollo”, which is a server that runs inside a v8 engine(node). It seems to me that the javascript crowd are the ones pushing this forward and seems to me that it was written with javascript as a first class citizen. Hard pass
erikpukinskis 6y ago
Does OpenAPI support multiple kinds of data in a single HTTP request? I couldn’t find anything about that in the docs.
- hardwaresofton 6y ago
  AFAIK there is not a standardized way to do this but there's no reason it can't -- you are free to define your own Content-Type or use framed binary, or whatever else. If you already have schemas on either side (or code to do dynamic discovery), and a way to pack/unpack you can send different kinds of data across. This is less ideal than GraphQL in this case, since GraphQL has done this hard work and standardized it/created the conforming reference clients/servers already.
dmitriid 6y ago
The one place where I've found GraphQL to be potentially useful is back office. This is usually the place where you need a lot of very different data in one place, and in ways that are completely different from customer-facing apps or sites. And back office usually doesn't get as much love. So usually you have backoffice devs scrambling to retrieve data in weird ways from existing APIs. And things like "does this inventory item come from a provider with an active contract, and who else is on that contract" become ... weird and unwieldy. This is where GraphQL with it's ad-hoc queries definitely helps. And since the volume of queries in back office is low, you don't worry too much about the performance of some of the queries. I wouldn't use it for anything else though. Anecdata: Just last month it took me about half an hour to implement an "omni search" functionality in GraphQL that takes string as input, coalesces results from three different backend APIs and return back a nice view to fuzzy-ish search for three different entities in our backend. Frontend couldn't be happier.
Lx1oG-AWb6h_ZG0 6y ago
The main advantage I’ve found with GraphQL is the normalized cache in client libraries like Apollo or Relay. It allows components to just ask for the data and not worry about how it’s fetched/stored/updated. The secondary benefit is that _some_ (not all) of the data plumbing can be moved from the frontend code to the backend, which makes for faster apps. Beyond that, GraphQL is more of a hinderance than a help... its type system in particular is brain dead and easily the worst part of the entire experience (seriously, why _is_ there a difference between inputs and types? Why can’t you define input unions, or maps, or recursive structures?) Is there any equivalent for the latter with swagger? Yes, you can do everything in there with custom redux middlewares or sagas/observables, but it’s more glue code you have to write and maintain.
- Ozzie_osman 6y ago
  If you just want the syntax and caching, you might try React Query. Haven't used it myself but it looks like it's Apollo-inspired.
- hardwaresofton 6y ago
  > The main advantage I’ve found with GraphQL is the normalized cache in client libraries like Apollo or Relay. It allows components to just ask for the data and not worry about how it’s fetched/stored/updated. The secondary benefit is that _some_ (not all) of the data plumbing can be moved from the frontend code to the backend, which makes for faster apps. Is this something you couldn't achieve with the idiomatic rules on HTTP request types, and serialization of HTTP requests parameters? It really depends on where you're trying to do the caching and what kind of caching you're trying to do. A lot of work has gone into HTTP headers, method semantics, and other details in order to facilitate caching. The "backend for frontend" pattern has been very popular as of late in order to try and shift the plumbing load, exposing endpoints that are catered to certain clients to boost efficiency -- would that be good enough for a corollary in OpenAPI land?
  - krschultz 6y ago
    The backend for frontend pattern is exactly why I got sold on GraphQL. We had a pile of relatively low value server code that could be replaced a GraphQL resolver and the client got all of the advantages of that pattern. The move to GraphQL genuinely freed up a lot of our time to work on more important problems. This was on a smallish team so that time mattered.
monadic5 6y ago
> Another week, another submission that hopefully edges more people towards realizing that they've just created an under-standardized, under-powered SQL-with-braackets that forces you to bring your own query optimizer, and eschews the advancements of Swagger/OpenAPI, JSONSchema, HAL, JSON-LD and the flexibility of HATEOAS. Why the insistence on condescending towards people who make decisions you don't understand? It's one of HN's less attractive aspects.

rand_r 6y ago

Does OpenAPI have a way for the client to whitelist fields? I see that as a major selling point for GraphQL. Without it, you end up having to create tailored endpoints for each use-case vs. for example a single “user” endpoint/vertex that supports the complete buffet of fields for all use-cases in one convenient place.

hardwaresofton 6y ago
I can't say that it should have that feature -- I'd say that is outside the purview of OpenAPI itself, but it could definitely be built in in a repeatable and scalable way pretty simply. I can tell you that tools like PostgREST have had this for a long time[0]. [0]: https://postgrest.org/en/v7.0.0/api.html#vertical-filtering-columns https://postgrest.org/en/v7.0.0/api.html#vertical-filtering-...

mikecaulley 6y ago

I've found GraphQL to greatly improve the developer experience when building web apps. As a front-end developer you can easily get a full view of the data and relationships. Tools like GraphiQL make exploring APIs a pleasure. And regardless of what you need to present to the user on screen, you can quickly build a request that perfectly matches the data you need. There is also the nice addition of strict typing and there are libraries that automatically generate TypeScript types for you from the schema and/or your operations.

jamil7 6y ago
I don't have especially strong feelings either way, but the majority of this is possible with OpenAPI as well.
kristaps 6y ago
I would like a backend developer perspective on the same. I haven't done any GraphQL stuff myself, but the "I can get whatever data I need" aspect feels like a huge potential headache for backend devs. Won't be a problem at prototype scale, but once you have a significant client count, how do you deal with unpredictable data access patterns that can't be optimized ahead of time?
- mikecaulley 6y ago
  Generally speaking, it's not more difficult than creating a REST API controller. Rather than mapping your service code to a controller, you map it to a (GraphQL) resolver. It feels extremely similar. There are different things to look out for; like handling n+1 (https://shopify.engineering/solving-the-n-1-problem-for-graphql-through-batching https://shopify.engineering/solving-the-n-1-problem-for-grap...) queries, but nothing that I can say is too difficult.
  - dmitriid 6y ago
    It is more difficult. With REST you know ahead of time which data you need, and you can optimise it as much as you can. With GraphQL at any given point in time you have no idea what the request is. Dataloaders solve it to some extent, but not much.
    - mikecaulley 6y ago
      Of course, you are building something that is much more powerful. If you intend every possible GraphQL operation to perform perfectly, it'll take more development effort. Though if you optimize for only the most likely cases, the effort is not much greater.

erikpukinskis 6y ago

I don’t really think of GraphQL as a data querying language like SQL. I think of it as a domain querying language. SQL is meant to allow you to write queries to your data model which are: - arbitrary, and - efficient I don’t think of GraphQL that way. I think of it as the place where you encode your set of valid domain actions (i.e. not arbitrary). And I don’t think the consumers of the GraphQL API should think about efficiency. They should just specify what data they need and then the backend is responsible for figuring out how to query the data model efficiently. In other words, I don’t really see any overlap between GraphQL and SQL in terms of the role they play in a stack. One helpful thing this distinction allows, is type inference. You can trivially write a type generator that gives you the type signature of a GraphQL query in any language. This is precisely because of its limitations. That allows you to automate the validation of your frontend and backend speaking the same language. You can’t easily infer the return types of arbitrary SQL queries. To me, that highlights the different purposes of the languages.

codenesium 6y ago
When your backend is sql how can you even do this efficiently? Databases require indexes. If you can query anything then there are performance bombs all over the place. It's different if you're querying elastic I guess.
- jkrems 6y ago
  > If you can query anything [...] The answer is simple: You can't. GraphQL _in general_ doesn't allow arbitrary queries. It allows arbitrary output field selection. But the filters are very explicit. It's more "pre-aggregation of request waterfalls and masking of outputs" than "querying a database". Doesn't stop people from exposing their SQL databases directly from GraphQL by generating a "free-for-all" schema. And when they do - yep, that's definitely a performance bomb and not a good use of GraphQL.
  - dmitriid 6y ago
    > The answer is simple: You can't. GraphQL _in general_ doesn't allow arbitrary queries. It really does. Surely, it somewhat limits the data that you get from it by defining a schema. But the moment you allow any nesting/connections between data in that schema, hello n+1 problem. And then every discussion of this problem on HN or elsewhere exposes the ugly truth: almost everyone uses GraphQL as a REST endpoint in production by limiting the actual queries you can run and curbing nesting.

jkcxn 6y ago

> replace the dynamic properties of the more advanced REST-ful techniques (API discovery, link following, etc) in GraphQL Isn't this exactly what GraphQL does? I may be missing something

humbleMouse 6y ago

100% agree. People also need to remember that GraphQL was originally written for server side javascript, and now it’s being ported to other languages(for what reason???). You can create your own global json schema and build a ratchet version of GraphQL using proven orms in about 20 minutes using an unpersisted “filtering” field. If you want automatic access to your data, bite the bullet and do something cool like implement Apache Dremio.

santialbo 6y ago
GraphQL was released as an specification with a node example implementation. It wasn't "written for server side javascript".
- humbleMouse 6y ago
  Ok, so it was software released with it’s first implementation written in node. And now have “Apollo”, which is a server that runs inside a v8 engine(node). It seems to me that the javascript crowd are the ones pushing this forward and seems to me that it was written with javascript as a first class citizen. Hard pass

erikpukinskis 6y ago

Does OpenAPI support multiple kinds of data in a single HTTP request? I couldn’t find anything about that in the docs.

hardwaresofton 6y ago
AFAIK there is not a standardized way to do this but there's no reason it can't -- you are free to define your own Content-Type or use framed binary, or whatever else. If you already have schemas on either side (or code to do dynamic discovery), and a way to pack/unpack you can send different kinds of data across. This is less ideal than GraphQL in this case, since GraphQL has done this hard work and standardized it/created the conforming reference clients/servers already.

dmitriid 6y ago

The one place where I've found GraphQL to be potentially useful is back office. This is usually the place where you need a lot of very different data in one place, and in ways that are completely different from customer-facing apps or sites. And back office usually doesn't get as much love. So usually you have backoffice devs scrambling to retrieve data in weird ways from existing APIs. And things like "does this inventory item come from a provider with an active contract, and who else is on that contract" become ... weird and unwieldy. This is where GraphQL with it's ad-hoc queries definitely helps. And since the volume of queries in back office is low, you don't worry too much about the performance of some of the queries. I wouldn't use it for anything else though. Anecdata: Just last month it took me about half an hour to implement an "omni search" functionality in GraphQL that takes string as input, coalesces results from three different backend APIs and return back a nice view to fuzzy-ish search for three different entities in our backend. Frontend couldn't be happier.

Lx1oG-AWb6h_ZG0 6y ago

The main advantage I’ve found with GraphQL is the normalized cache in client libraries like Apollo or Relay. It allows components to just ask for the data and not worry about how it’s fetched/stored/updated. The secondary benefit is that _some_ (not all) of the data plumbing can be moved from the frontend code to the backend, which makes for faster apps. Beyond that, GraphQL is more of a hinderance than a help... its type system in particular is brain dead and easily the worst part of the entire experience (seriously, why _is_ there a difference between inputs and types? Why can’t you define input unions, or maps, or recursive structures?) Is there any equivalent for the latter with swagger? Yes, you can do everything in there with custom redux middlewares or sagas/observables, but it’s more glue code you have to write and maintain.

Ozzie_osman 6y ago
If you just want the syntax and caching, you might try React Query. Haven't used it myself but it looks like it's Apollo-inspired.
hardwaresofton 6y ago
> The main advantage I’ve found with GraphQL is the normalized cache in client libraries like Apollo or Relay. It allows components to just ask for the data and not worry about how it’s fetched/stored/updated. The secondary benefit is that _some_ (not all) of the data plumbing can be moved from the frontend code to the backend, which makes for faster apps. Is this something you couldn't achieve with the idiomatic rules on HTTP request types, and serialization of HTTP requests parameters? It really depends on where you're trying to do the caching and what kind of caching you're trying to do. A lot of work has gone into HTTP headers, method semantics, and other details in order to facilitate caching. The "backend for frontend" pattern has been very popular as of late in order to try and shift the plumbing load, exposing endpoints that are catered to certain clients to boost efficiency -- would that be good enough for a corollary in OpenAPI land?
- krschultz 6y ago
  The backend for frontend pattern is exactly why I got sold on GraphQL. We had a pile of relatively low value server code that could be replaced a GraphQL resolver and the client got all of the advantages of that pattern. The move to GraphQL genuinely freed up a lot of our time to work on more important problems. This was on a smallish team so that time mattered.

monadic5 6y ago

> Another week, another submission that hopefully edges more people towards realizing that they've just created an under-standardized, under-powered SQL-with-braackets that forces you to bring your own query optimizer, and eschews the advancements of Swagger/OpenAPI, JSONSchema, HAL, JSON-LD and the flexibility of HATEOAS. Why the insistence on condescending towards people who make decisions you don't understand? It's one of HN's less attractive aspects.