Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
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.
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.