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

This page summarizes the projects mentioned and recommended in the original post on

Our great sponsors
  • InfluxDB - Access the most powerful time series database as a service
  • SonarLint - Clean code begins in your IDE with SonarLint
  • SaaSHub - Software Alternatives and Reviews
  • postgrest

    REST API for any Postgres database

    It's neither MySQL nor Go, but has figured out most of the patterns and API designs you could follow.

  • pg_ivm

    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

    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

    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).

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts