3 ms·
I worked on OpenAPI itself and have been working on the tooling since. I recently switched to GraphQL for a project and god damn! The GraphQL design is nearly p
by msoad 5y ago
I worked on OpenAPI itself and have been working on the tooling since. I recently switched to GraphQL for a project and god damn! The GraphQL design is nearly perfect and achieves whatever OpenAPI or AsyncAPI was hoping to achieve. If you have an existing JSON over HTTP (Let's not call them RESTful) API then it's harder to switch to GraphQL, but if you have a new project and want type-safety and efficiency, you must give GraphQL a shot instead of writing "hopefully will be enforced in runtime API specs".
- lijogdfljk 5y agoIs GraphQL useful to people who write a lot of custom-written JSON APIs? Things that are much more than cleanly mapping JSON to CRUD SQL? Ie i often think of GraphQL as a DSL for translating JSON to SQL. To let the caller define the query and data needed. This looks great for SQL, but if i write a custom API with non-SQL generated data, maybe in some custom data structures, the idea of supporting arbitrary querying over my data structures seems .. difficult. Is GraphQL applicable to more than basic SQL data querying?
- nlarew 5y agoGraphQL can do anything that a REST API can do, it's just a different interface over HTTP at the end of the day. There's nothing that particularly links it to SQL or any other data store, though some tools might add that coupling, especially if they're "schema-first". You can write query and mutation resolvers that generically do read and write operations. The resolvers are just strongly typed functions - they take in user-provided inputs and return a defined output that users can select a subset of fields from (inputs/outputs are defined in your schema). As long as you can access your data from your backend (whether it's in a SQL db, mongo, s3, or some custom data structure) then you can do whatever processing you want in your queries and mutations.