pronto
SQLBoiler
pronto | SQLBoiler | |
---|---|---|
4 | 42 | |
6 | 6,453 | |
- | 1.2% | |
0.0 | 7.7 | |
over 3 years ago | 18 days ago | |
Java | Go | |
MIT License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pronto
-
Buf raises $93M to deprecate REST/JSON
5. Message streaming (gRPC streams are amazing)
I can think of a whole host of features that can be built off of protos (I've even built ORMs off of protobuffs for simple things [0]). The value prop is there IMO. HTTP + json APIs are a local minima. The biggest concerns "I want to be able to view the data that is being sent back and forth" is a tooling consideration (curl ... isn't showing you the voltages from the physical layer, it is decoded). Buff is building that tooling.
[0] - https://github.com/CaperAi/pronto
-
Parsing Gigabytes of JSON per Second
I've written translation layers for such systems and it's not too bad. See this project from $job - 1: https://github.com/CaperAi/pronto
It allowed us to have a single model for storage in the DB, for sending between services, and syncing to edge devices.
-
gRPC for Microservices Communication
There's no reason you couldn't use gRPC with json as a serialized message format. For example grpc-gateway [0] provides a very effective way of mapping a gRPC concept to HTTP/JSON. The thing is, after moving to gRPC, I've never really felt a desire to move back to JSON. While it may be correct to say "parsing json is fast enough" it's important to note that there's a "for most use cases" after that. Parsing protos is fast enough for even more use cases. You also get streams which are amazing for APIs where you have to sync some large amounts of data (listing large collections from a DB for example) across two services.
With gRPC you also have a standardized middleware API that is implemented for "all" languages. The concepts cleanly map across multiple languages and types are mostly solved for you.
Adding to that you can easily define some conventions for a proto and make amazing libraries for your team. At a previous job I made this: https://github.com/CaperAi/pronto/
Made it super easy to prototype multiple services as if you mock a service backed by memory we could plop it into a DB with zero effort.
I think this "gRPC vs X" method of thinking isn't appropriate here because protos are more like a Object.prototype in JavaScript. They're a template for what you're sending. If you have the Message you want to send you can serialize that to JSON or read from JSON or XML or another propriety format and automatically get a host of cool features (pretty printing, serialization to text/binary, sending over the network, etc).
[0] - https://github.com/grpc-ecosystem/grpc-gateway
-
We Went All in on Sqlc/Pgx for Postgres and Go
I attempted to make something similar to this except the opposite direction at a previous job. It was called Pronto: https://github.com/CaperAi/pronto/
It allowed us to store and query Protos into MongoDB. It wasn't perfect (lots of issues) but the idea was rather than specifying custom models for all of our DB logic in our Java code we could write a proto and automatically and code could import that proto and read/write it into the database. This made building tooling to debug issues very easy and make it very simple to hide a DB behind a gRPC API.
The tool automated the boring stuff. I wish I could have extended this to have you define a service in a .proto and "compile" that into an ORM DAO-like thing automatically so you never need to worry about manually wiring that stuff ever again.
SQLBoiler
-
Go ORMs Compared
SQLBoiler takes a database-first approach, generating Go code from your database schema. This means it creates highly optimized and custom-tailored code for your specific database schema. SQLBoiler is great for applications where the database schema is well-defined and changes infrequently. However, like sqlc, it requires regenerating the code when the database schema changes. It's well-suited for projects where performance is a key concern and the database design is stable.
-
Comparing database/sql, GORM, sqlx, and sqlc
Moved all my projects to https://github.com/volatiletech/sqlboiler.
-
Are there any decent ORMs in Golang?
sqlboiler
-
Any mid sized / big open source code base in golang that makes use of SQL DBs?
My current ORM of choice is Bob [GitHub Link] which I created based on my experience using and maintaining SQLBoiler [GitHub Link].
-
GORM
You mean like ORMs? * sqlboiler: generates Go ORM using database schema.
-
ORM or no ORM (and which ones)?
SQL code generator (aka inspect a database or SQL files to generate data models). You have the option of using something like volatiletech/sqlboiler which looks at the a physical database and generates code based on the schema. Or SQLC which is an amazing and fast project.
-
Using Prisma Migrate with a Dockerized Postgres
After trying a half dozen migration engines for NodeJS, I was pleased to see Prisma and its excellent documentation. As a golang developer I am partial to SQLBoiler and its database-first approach, though perhaps this is a condition of our community where we want all the knobs. Prisma was code-first but still gave me enough control to feel confident.
-
Can anyone help me on how you are using golang with databases in production systems?
I use sqlboiler which generates an ORM from your database, and sql-migrate which is a tool for managing SQL migrations. Although you have to write your migrations in SQL, which IMHO is a plus.
- volatiletech/sqlboiler: Generate a Go ORM tailored to your database schema.
-
Go overtook Ruby and ranked #3 among the most used backend languages for pull requests since 2021
FWIW, the other posts point to https://gobuffalo.io/ and https://github.com/volatiletech/sqlboiler as possibilities.
What are some alternatives?
simd-json - Rust port of simdjson
GORM - The fantastic ORM library for Golang, aims to be developer friendly
pike - Generate CRUD gRPC backends from single YAML description.
sqlc - Generate type-safe code from SQL
sqlparser-rs - Extensible SQL Lexer and Parser for Rust
ent - An entity framework for Go
grpc-gateway - gRPC to JSON proxy generator following the gRPC HTTP spec
sqlx - general purpose extensions to golang's database/sql
pggen - A database first code generator focused on postgres
go-pg - Golang ORM with focus on PostgreSQL features and performance
sqlite
upper.io/db - Data access layer for PostgreSQL, CockroachDB, MySQL, SQLite and MongoDB with ORM-like features.