Using Ent ORM in bud

[dangerzone]

Hi, what are your thoughts on using Ent ORM in bud for the M in MVC?

It has a large user base and active contributors, supports multiple DB drivers, uses code generation for static typing, and handles migrations. It also has fantastic documentation.

Using Ent would reduce the dev and maintenance burden over creating something from scratch.

I'm sure you all have thought about this a lot and have looked into Ent. I'm curious what you think about using it in the context of bud.

[matthewmueller]

Hey, thanks for your message! I really like how https://ent.io allows for a GraphQL like graph traversal experience within your ORM. It's also an extraction of an internal FB framework with the same name that FB uses everywhere.

Does ent.io support introspection? Last I checked, you can't tie your database structure to your Ent models. If not, this is my main issue with ent, gorm, etc. The programmer is responsible for keeping the database schema in sync with the models.

I'm more interested in the approaches that https://github.com/xo/xo and https://sqlc.dev/ take where they understand the structure of your DB and generate code that matches that structure. Then when you migrate your DB, the model code is regenerated and type-checking kicks in.

I also think you can generate code that provides a lot of the wins that Ent.io provides with it's awesome traversal experience.

You're right though, this comes at the expense of dev and maintenance burden that comes from creating something from scratch. I think the M is going to be important enough for applications that it's going to be worth a tight integration into Bud though.

That being said, https://github.com/vito/bass-loop has demonstrated you can bring your own M, so using ent with Bud would probably not be out of the question if you prefer that over what Bud provides.

[dangerzone]

Thanks for the quick reply.

Does ent.io support introspection? Last I checked, you can't tie your database structure to your Ent models. If not, this is my main issue with ent, gorm, etc. The programmer is responsible for keeping the database schema in sync with the models.

It does support DB introspection and can automatically create versioned migration files that can(should!) be checked into git. The versioned migration files can then be run with something like golang-migrate/migrate

It uses Atlas under the hood to do the introspection. More info in the Ent docs

I'll admit I haven't used Ent yet, but have read the docs and am looking forward to using it on my next project.

[dangerzone]

I would like to clarify something here. Tools like xo largely leave database schema versioning as an "exercise for the reader". Once a schema change has happened, then xo runs and generates new Go code that is then checked in to git.

Ent's versioned migrations take the opposite approach. Ent uses the Go schema definition files as the desired state. It introspects the DB, computes the changes required to reach the desired state, and then outputs a migration file. It's a declarative approach to schema change management that ensures everything is in sync.

[matthewmueller]

Ah awesome, thanks for sharing. Ent indeed seems to have a come a long ways since I last looked at it. It seems like it's more like https://prisma.io with a declarative schema (e.g. schema.prisma) in your app being the source of truth.

I'll have a closer look at ent.io again before making any decisions here!

[austincollinpena]

Big vote for sqlc.dev for me!

[dangerzone]

Could you expand a bit on why you feel sqlc.dev might be a better fit than Ent please?

[austincollinpena]

I mean, that's a big question mostly focused on sqlc.dev vs ent.io.

I like you sqlc.dev on my projects because I think that writing SQL is the fastest way to produce correct code. I can test my queries against my database without running any code.

Plus, I can easily write more complicated queries with confidence.

If it's all autogenerated anyway, why not choose the tool that provides the better escape hatch anyway?