I think Ent for Go has a ton of potential. Although I haven’t used this library, I have spent a lot of time studying the design space of ORMs because I’m currently iterating on an internal library that does ORM-like things at Notion. I really like the Ent approach because it allows working with a graph-based data model directly in the embedding language, instead of forcing developers to learn a new query language like Datomic datalog or SPARQL, while simultaneously avoiding lock-in to a specific data store backend.

I would like to build something like Ent that is ergonomic and usable on both the client and the server in Typescript, and facilitates easily moving business logic between the two. The context at Notion is that we have a very smart client using something ORM-like and a somewhat dumb server using plain row record values, so while we do share some code between the two, it’s difficult to port larger features from the client to the server. It’s kind of the reverse situation that most people have, which is a smart server pushing GraphQL to a relatively dumb client.

There are a lot of people looking into client-focused or end-to-end database abstractions right now, so the space exciting. What the upstarts should learn from Ent is:

1. Codegen is powerful, and often easier to understand than a mountain of typelevel magic.

2. A good ORM solution should really build in permissions and composing mutations at a deep level. The previous generation of ORMs like ActiveRecord left this stuff to user space to everyone’s detriment.

3. Embedded DSL as query language is a blessing and a curse. It’s better than forcing engineers to learn a weird alternative to SQL strings, but more frustrating to experts. Use these tradeoffs with caution!