awesome-go-orms VS pgx

> we'd see the same problem everywhere at the same scale

we do. Every C app implements its own linked list or hash table library. The entire Scheme community is nothing but toy interpreters of various stages of completeness (you can tell a project is serious when they implement call/cc). How many game engines do you think exist? It's a meme that game devs like to spend more time on their pet game engine than actually making their game. How many ORMs do you think exist for ? At least half a dozen. At least. For any given language. Python, Ruby, Go[1]. ORMs, in particular, seem to get created over and over again. Probably because they are trivial to implement and allows one to voice their opinions on SQL abstraction (bike shedding).

[1] https://github.com/d-tsuji/awesome-go-orms

I created a PR to add Ent to the list. See https://github.com/d-tsuji/awesome-go-orms/pull/8

The infrastructure layer contains the concrete implementation of the repository domain interface ActivityRepository in the struct DbActivityRepository. This repository implementation uses the Postgres driver pgx and plain SQL to store the activity in the database. It uses the database transaction from the context, since the transaction was initiated by the application service.

For building the RESTful Point of Sale service API, I've considered and selected a combination of technologies that would work seamlessly together. For handling HTTP requests and responses, using the Gin HTTP web framework would make sense because I think it seems complete and popular among Go community too. To ensure data integrity and persistence, I'm using PostgreSQL database with pgx as the database driver, the reason I choose PostgreSQL because it is the most popular relational database to use in production and offers efficient Go integration. I'm also implementing caching using Redis with go-redis client library, which provides powerful in-memory data storage capabilities.

If you are willing to commit to working only with Postgres, I highly recommend pgx. Be sure you get the latest version github.com/jackc/pgx/v5. This gives you the full power of interacting with Postgres without going through an intermediate lowest-common-denominator library.

It uses pg package and pgx driver under the hood.

Starting off, is there any reason you're calling out to the CLI, instead of just using a Postgres driver like pgx? Shelling out to the command line should always be a last resort where possible as a software engineer.

For maintaining state I use PostgreSQL. Driver: https://github.com/jackc/pgx (I use the pgxpools) Along with Sqlc for generating database models and allowing me to focus on just building queries in DBeaver. https://sqlc.dev/

An example of what I'm looking for can be found here https://github.com/jackc/pgx/wiki/Getting-started-with-pgx-through-database-sql/c9f798b4d9a500fcf93931df2464af969d68f516

Except pgx recommends using their native interface, not database/sql, for performance and extra features [0], so it's not that simple in practice.

[0]: https://github.com/jackc/pgx#choosing-between-the-pgx-and-da...

pgx is “PostgreSQL driver and toolkit for Go”. Take a look at https://github.com/jackc/pgx

the postgres pgx driver supports this usecase: https://github.com/jackc/pgx/issues/676