4 ms·

I've found the opposite. Designing a GraphQL API with the extended tail of important features has been an awful lot harder than with REST Apis. That's not just

I've found the opposite. Designing a GraphQL API with the extended tail of important features has been an awful lot harder than with REST Apis. That's not just in terms of idioms (which are useful for abstraction layer sake), but authorization, performance, all the sorts of things that are very known quantities, with extensive framework integration, in REST land. You get a lot farther with the wide ecosystem of tracing and monitoring tools, API gateways, authenticating proxies, all these API integration points and what have you in JSON api land. In specific language ecosystems with a specific choice of tooling and libraries you can ultimately make good things happen, but it's not nearly as universal. Apollo is an obvious contender. I also like HotChocolate in the dotnet ecosystem. There are definitely benefits. GraphQL having typed schematization by default is huge, and arguably that's the best feature. That's something you need to be more disciplined about in REST land (e.g. OpenAPI). But there's good tooling to be had on those fronts as well. Arbitrarily-shaped types definitely come with their own set of maintenance challenges versus more static DTOs. P.S. HotChocolate's EFCore integration [0] is some of the coolest library tech I've seen. Thanks to C#'s builtin data projection functionality (via LINQ), it's able to automatically build a Hasura-style fully baked GraphQL API directly from your database domain model (which you can transform arbitrarily to limit / add additional functionality to via LINQ). It's still not my default choice in a new app, but if I were going to invest in GraphQL it's probably the strongest contender [0]: https://chillicream.com/blog/2020/03/18/entity-framework https://chillicream.com/blog/2020/03/18/entity-framework

nivertech 5y ago
IMO every technology have some minimal accepted level of code quality. Usually it depends on the community or ecosystem, not the tech per say. I.e. usually the code quality of Matlab code will be lower than of C++. IMO code quality of projects using REST-like HTTP APIs is usually lower than the corresponding projects using GraphQL APIs. Just like some people do not care to learn Javascript properly because of its perceived simplicity, for the same reason they are also don't care to learn REST properly. How many of HTTP APIs have a corresponding OpenAPI spec? And if they have, is it actually kept in sync with the code? Does it have proper type definitions, or everything is of a type "string"? If you are a Stripe you can design a perfect RESTful HTTP API, but for a smaller shop it's much easier to build a moderately good GraphQL API than a corresponding quality HTTP API. GraphQL forces you: 1. to learn it, instead of blindly using code generated by your web framework 2. to think about your schema 3. to think about backward and forward compatibility, how you your schema will evolve 3. to apply CQS (Command/Query separation) 4. to think how to properly do pagination 5. to think about security 6. to think about error handling, error retries and idempotency of your mutations etc. EDIT: For me personally GraphQL was one of the triggers to start serious research on Software Engineering, Software Correctness and Code Quality.
- aniforprez 5y ago
  > IMO code quality of projects using REST-like HTTP APIs is usually lower than the corresponding projects using GraphQL APIs > How many of HTTP APIs have a corresponding OpenAPI spec? And if they have, is it actually kept in sync with the code Umm what? Is this specific to NodeJS or something? Cause Django and DRF allow one to very easily and very quickly creating high quality REST APIs that are self-documenting and trivial to maintain. Pretty sure rails and go have similar packages and methods to allow for making excellent REST APIs. In fact I've found it a massive pain and a huge performance cost to add GraphQL to such projects. It's far slower than the REST calls

nivertech 5y ago

IMO every technology have some minimal accepted level of code quality. Usually it depends on the community or ecosystem, not the tech per say. I.e. usually the code quality of Matlab code will be lower than of C++. IMO code quality of projects using REST-like HTTP APIs is usually lower than the corresponding projects using GraphQL APIs. Just like some people do not care to learn Javascript properly because of its perceived simplicity, for the same reason they are also don't care to learn REST properly. How many of HTTP APIs have a corresponding OpenAPI spec? And if they have, is it actually kept in sync with the code? Does it have proper type definitions, or everything is of a type "string"? If you are a Stripe you can design a perfect RESTful HTTP API, but for a smaller shop it's much easier to build a moderately good GraphQL API than a corresponding quality HTTP API. GraphQL forces you: 1. to learn it, instead of blindly using code generated by your web framework 2. to think about your schema 3. to think about backward and forward compatibility, how you your schema will evolve 3. to apply CQS (Command/Query separation) 4. to think how to properly do pagination 5. to think about security 6. to think about error handling, error retries and idempotency of your mutations etc. EDIT: For me personally GraphQL was one of the triggers to start serious research on Software Engineering, Software Correctness and Code Quality.

aniforprez 5y ago
> IMO code quality of projects using REST-like HTTP APIs is usually lower than the corresponding projects using GraphQL APIs > How many of HTTP APIs have a corresponding OpenAPI spec? And if they have, is it actually kept in sync with the code Umm what? Is this specific to NodeJS or something? Cause Django and DRF allow one to very easily and very quickly creating high quality REST APIs that are self-documenting and trivial to maintain. Pretty sure rails and go have similar packages and methods to allow for making excellent REST APIs. In fact I've found it a massive pain and a huge performance cost to add GraphQL to such projects. It's far slower than the REST calls