|
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. original promotional piece:
https://news.ycombinator.com/item?id=25600934 docker implementation:
https://github.com/sudowing/service-engine-template youtube playlist:
https://www.youtube.com/playlist?list=PLxiODQNSQfKOVmNZ1ZPXb... |