Indeed. Thats actually how my team's FE engineers called our API.
But once other teams started integrating -- we heard all kinds of feedback.
My thoughts afterward were simply that people under the time pressure to push features daily had different appetites for any friction in their workflow.
We considered the feedback from the larger team and intentionally added support for both REST & GraphQL in our next app. We wanted to support anyone that wanted some exposure to it without forcing anyone. And that had much better feedback from consumers.
I've put a couple GraphQL services into production and have similar thoughts.
What suprised me most were the range of views from colleagues when they needed to integrate into one of their products. Some people were happy to work with something new, while others didn't appreciate the tax involved with the learning curve.
That said, I published an app that auto-provisions a CRUD service in GraphQL. So while I may not use it for most apps, I use this for general data-access.
I published an app via docker that can be used for db migrations with all dbs supported by knex.js
I'm pretty sure the core migration functionality provided by knex is supported -- along with some project specific features which support more modular schema migrations via batches of SQL files held within specific directories.
Shameless plug... sure. But it may be useful to anyone interested in the topic of this post.
I spent a much of 2020 developing a project that auto provisions REST, GraphQL & gRPC services that support CRUD operations (with full validation) to tables, views and materialized views of several popular databases (postgres, postgis, mysql, sqlite).
Features include: Full CRUD, geoquery support (bbox, radius, custom wkt polygon) complex_resources (aggregate & sub queries), middleware (access the query before db execution), permissions (table/view level CRUD configs), field redaction (enable query support -- without publication), schema migrations, auto generated openapi3/swagger docs, auto generated proto file, full validation.
The `versus` nature of this question was the driving force behind a project I built last year.
I've been in multiple shops where REST was the standard -- and while folks had interest in exploring GraphQL or gRPC, we could not justify pivoting away from REST to the larger team. Repeatedly faced with this `either-or`, I set out to build a generic app that would auto provision all 3 (specifically for data-access).
I posted in verbose detail about that project a few months ago, so here I'll just provide a summary: The project auto provisions REST, GraphQL & gRPC services that support CRUD operations to tables, views and materialized views of several popular databases (postgres, postgis, mysql, sqlite). The services support full CRUD (with validation), geoquery (bbox, radius, custom wkt polygon), complex_resources (aggregate & sub queries), middleware (access the query before db execution), permissions (table/view level CRUD configs), field redaction (enable query support -- without publication), schema migrations, auto generated openapi3/swagger docs, auto generated proto file.
I hope this helps anyone in a spot where this `versus` conversation pops up.
But once other teams started integrating -- we heard all kinds of feedback.
My thoughts afterward were simply that people under the time pressure to push features daily had different appetites for any friction in their workflow.
We considered the feedback from the larger team and intentionally added support for both REST & GraphQL in our next app. We wanted to support anyone that wanted some exposure to it without forcing anyone. And that had much better feedback from consumers.