3 ms·

Appreciate your response. This sounds exactly what SOAP is like, then, and also what OpenAPI/JSON schema are attempting to do (only SOAP/WSDL also adds auth, tr

Appreciate your response. This sounds exactly what SOAP is like, then, and also what OpenAPI/JSON schema are attempting to do (only SOAP/WSDL also adds auth, transactions, discoverability, language mappings, schema evolution, and a couple other things). My post surely wasn't meant to defend "REST" or Swagger of all things :); more like, the industry has delivered one middleware standard after another in the last 20 years since "web services" became a thing, and arguably even earlier (CORBA). So it wasn't quite clear for me where this enthusiasm was coming from all along. Please don't be offended, but your answer confirms my suspicion that GraphQL is introducing an age-old concept to a new audience that was raised in the naive "REST all the things" mood of the last decade. From the other answers, I get there's additional practical functionality like generic sorting and filtering in a GraphQL endpoint, though as a fullstack but mostly backend guy I'm puzzled how that's supposed to work without pushing the query criteria including sorting/offset/limit down to a DB in a hands-off way without a backend team implementing it.

tango12 7y ago
You're right. GraphQL definitely seems like that. There are a few nuances though: 1. GraphQL is like SOAP for JSON. JSON is important to lot of developers today, especially the frontend/javascript ecosystem 2. GraphQL also helps developers think of data as related entities in a way that fits JSON. Nested objects and arrays essentially, but not ad-hoc. Hence a "schema" of your "graph" that describes the API. 3. GraphQL has a construct called fragments that makes it easy to declare data-dependencies at a UI component level that are then automatically composed together into a single query by graphql client tooling (at build time ideally). This can be done with JSON as well, but the ergonomics with GraphQL are nicer. None of these are truly "new" ideas perhaps. But I think all of it coming together is new. That said, the complexity of building and maintaining a GraphQL server is definitely non-trivial in the real world. For example, health-check tools often rely on HTTP status codes in responses to check service and API health. This doesn't work well with GraphQL because GraphQL supports partial errors and responses, and the error itself is embedded inside the response. This means analysis the response is necessary. This means that the privilege required for the health-check tooling is greater. Responses should not be logged or analysed by third party services without taking a lot of explicit care.
hn_throwaway_99 7y ago
I worked extensively with SOAP in the early 00s. I hated every living minute of having to deal with SOAP (completely overcomplicated, bad tooling), and I love programming with GraphQL.

tango12 7y ago

You're right. GraphQL definitely seems like that. There are a few nuances though: 1. GraphQL is like SOAP for JSON. JSON is important to lot of developers today, especially the frontend/javascript ecosystem 2. GraphQL also helps developers think of data as related entities in a way that fits JSON. Nested objects and arrays essentially, but not ad-hoc. Hence a "schema" of your "graph" that describes the API. 3. GraphQL has a construct called fragments that makes it easy to declare data-dependencies at a UI component level that are then automatically composed together into a single query by graphql client tooling (at build time ideally). This can be done with JSON as well, but the ergonomics with GraphQL are nicer. None of these are truly "new" ideas perhaps. But I think all of it coming together is new. That said, the complexity of building and maintaining a GraphQL server is definitely non-trivial in the real world. For example, health-check tools often rely on HTTP status codes in responses to check service and API health. This doesn't work well with GraphQL because GraphQL supports partial errors and responses, and the error itself is embedded inside the response. This means analysis the response is necessary. This means that the privilege required for the health-check tooling is greater. Responses should not be logged or analysed by third party services without taking a lot of explicit care.

hn_throwaway_99 7y ago

I worked extensively with SOAP in the early 00s. I hated every living minute of having to deal with SOAP (completely overcomplicated, bad tooling), and I love programming with GraphQL.