Our great sponsors
-
Hey, I may be a bit biased, because I am the creator of Ent. I don't think there's one true answer here. It depends on the problem you try to solve and the scope of your data layer, but these are my opinions based on my experience.
-
This is the approach I've taken took, though instead of writing new helpers, I've preferred to use goqu. I've only been using the query building features, but it is excellent for it.
-
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.
-
-
This is what I've been doing for the past 2 years. Repository pattern (in its own grpc/proto service) + sqlc. We also use squirrel in one or two places where we want to filter on certain objects in various ways and we'd end up with too many queries. But 95% of our repository service uses sqlc.
-
However, there *are* senior engineers who think business logic can and should be stored in the database. I haven't played with it, but you may be interested to look at https://supabase.com/, which embraces that philosophy. They're building it on the back of postgres, with plans to take advantage of postgres' advanced features.
-
There is nothing stopping you from taking the same approach when you put business logic in the database. You can, if you wish, create an 'api' schema that contains views and stored procedures through which the underlying database can be accessed. Same solution of an API layer, but centralised in the database so any service from any language can access the same window, but with more power and efficiency than going through an intermediary service. You can even expose it as a REST API using https://postgrest.org.
