grpc-go VS pgx

The reflection service is open-sourced (at least for some sdks):

* https://github.com/grpc/grpc-go/blob/master/Documentation/se...

* https://chromium.googlesource.com/external/github.com/grpc/g...

We’re hoping to make this rate at least optional via this pull request but as the time of writing this blog, it’s nothing we can do to circle our way around it.

First, I started with gRPC’s recommended starter repository for learning gRPC, their **helloworld **example, which is a part of the official gRPC repository.

IDE: use whatever make you productive. I personally use vscode. VCS: git, as golang communities use github heavily as base for many libraries. AFAIK Linter: use staticcheck for linting as it looks like mostly used linting tool in go, supported by many also. In Vscode it will be recommended once you install go plugin. Libraries/Framework: actually the standard libraries already included many things you need, decent enough for your day-to-day development cycles(e.g. `net/http`). But here are things for extra: - Struct fields validator: validator - Http server lib: chi router , httprouter , fasthttp (for non standard http implementations, but fast) - Web Framework: echo , gin , fiber , beego , etc - Http client lib: most already covered by stdlib(net/http), so you rarely need extra lib for this, but if you really need some are: resty - CLI: cobra - Config: godotenv , viper - DB Drivers: sqlx , postgre , sqlite , mysql - nosql: redis , mongodb , elasticsearch - ORM: gorm , entgo , sqlc(codegen) - JS Transpiler: gopherjs - GUI: fyne - grpc: grpc - logging: zerolog - test: testify , gomock , dockertest - and many others you can find here

If you read the first comment, you’ll see the API was documented as being experimental.

https://github.com/grpc/grpc-go/issues/3798#issuecomment-670...

The lack of this analysis still results in bugs and CVEs. See how many races are found and fixed in gRPC releases: https://github.com/grpc/grpc-go/releases (search "race"). It's a shame Google does not publish these as CVEs, because many of them qualify.

I like to point people at this release to show that not even Google -- in its own language on its own library for its own RPC protocol -- can write thread-safe Go, so what chance does anyone else have. Maybe we have to stop thinking of Go as a language for mission critical parallel computing and think of it more like a Python 4 made for low-risk prototyping. Mature libraries help for that prototyping, you know how to put them together and get something working, that something just won't be scaleable, efficient, or thread-safe.

I first learned about this technique when gRPC generated code started using it. See the short readme and the long issue discussion. I think a lot more of the rationale from the discussion should have made it into the readme, since this is the only time most Go developers will ever see this technique used, especially since it can't be retrofitted to existing interfaces without breaking existing implementations.

I don't have any experience with goRPC (I'm assuming you're referring to https://github.com/valyala/gorpc), but just to note that that repo hasn't been updated in 7 years and has open issues that are that old, too. https://github.com/grpc/grpc-go has 17.5k stars and is actively maintained. That doesn't say anything about their relative performance - goRPC might be faster - but you probably won't have a fun time if you run into issues.

Found the root cause from https://github.com/grpc/grpc-go/commit/383b1143 (original issue: https://github.com/grpc/grpc-go/issues/75):

    // Note that ServeHTTP uses Go's HTTP/2 server implementation which is

Sometimes, backend developers tend to opt for an ORM library because it provides an abstraction between your app and the database and thus there is little or no need to write raw queries and migrations which is nice. However, if you want to get better at writing queries (SQL for example), you need to learn how to build your repositories without an ORM. To open a database handle, you can either do it directly from the database driver or do it from database/sql with the driver passed into it. I will be opening the connection with database/sql together with pgx which is a driver and toolkit for PostgreSQL. Walk with me.

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