Should I replace all db select query REST APIs with a single generic router ?

• postgrest

  42 20,236 8.7 Haskell

  REST API for any Postgres database

  

  It's neither MySQL nor Go, but https://github.com/PostgREST/postgrest has figured out most of the patterns and API designs you could follow.

• pg_ivm

  14 427 7.9 C

  IVM (Incremental View Maintenance) implementation as a PostgreSQL extension

  

  It makes sense to perform managed denormalization - use a materialized view or automatically refresh a table or foreign server (via FDW) using common triggers (like pg_ivm does). And it's fine to add a TTL to it and use as a read store... update on user login and make a partial index just for that. And that's how you could get CQRS...

• InfluxDB

  www.influxdata.com

  sponsored

  Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.

  

• contour

  3 3,347 10.0 HTML

  Contour is a Kubernetes ingress controller using Envoy proxy.

  

  Practically, it makes more sense to adopt GRPC services and publish them using REST/GraphQL bridges/gateways, respective API Gateways (I prefer Contour). Those have some AAA requirements and limitations on their own, and shape the design for everything else, including observability and service delivery (i.e. blue green vs canary).

Suggest a related project