Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ent: An Entity Framework for Go

github.com

Post reply on HN
Print view View original

21–30 of 68 posts

Re: Ent: An Entity Framework for Go

#21

Post by lordofgibbons »

ivanvanderbyl wrote: post #15
metadat wrote: post #2

I thought this looked familiar.. Discussed 2 years ago: https://news.ycombinator.com/item?id=26008521 . (39 points, 9 comments)

I first heard about Ent on HN about 2 years ago. At the time I was evaluating every ORM in Go to find something that would fit the bill and Ent happened to be exactly what we needed. We've now been using it for 2 years and it's been one of the best bets we made on a technology choice. Things that have worked really well: * Auto DB migrations using Ent+Atlas. Ent implements a lot of great low level defaults that I jus…

>* Generating our GraphQL API from Ent Schema

How do you make sure you don't accidentally expose an-authorized data to the user with auto-generating GraphQL APIs? Does Ent have built-in authorization validation?

Re: Ent: An Entity Framework for Go

#23

Post by ivanvanderbyl »

lordofgibbons wrote: post #21
ivanvanderbyl wrote: post #15

Earlier quoted context omitted.

I first heard about Ent on HN about 2 years ago. At the time I was evaluating every ORM in Go to find something that would fit the bill and Ent happened to be exactly what we needed. We've now been using it for 2 years and it's been one of the best bets we made on a technology choice. Things that have worked really well: * Auto DB migrations using Ent+Atlas. Ent implements a lot of great low level defaults that I jus…

>* Generating our GraphQL API from Ent Schema How do you make sure you don't accidentally expose an-authorized data to the user with auto-generating GraphQL APIs? Does Ent have built-in authorization validation?

I should have mentioned this, Ent has built in authorization at the row level: https://entgo.io/docs/privacy

There are some gotchas with this, but like all auth you need to take the time to think through it and once you do it is extremely powerful. This approach means you can essentially forget about needing to scope queries to specific users throughout your codebase as Ent will automatically apply that part of the query wherever it is needed.

I know there's been some comments on this thread and others about coupling auth to your ORM, I think it's necessary as it's otherwise too easy to forget this somewhere deep in your code and accidentally expose everything to the wrong user.

Re: Ent: An Entity Framework for Go

#24

Post by bokwoon »

Fire-Dragon-DoL wrote: post #4
jitl wrote: post #3

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 lik…

I keep thinking that the query portion should be entirely split from the ORM portion. Query builder have specific usage, but are not the norm. None of them can model an advanced postgres query, but at the same time, they provide little (or nothing) utilities to map the data coming from a complex query, back to objects, which is funny, to me that would be the definition of "object relational mapper". I know why active…

> at the same time, they provide little (or nothing) utilities to map the data coming from a complex query, back to objects

Example of a query builder with built-in mapping capabilities (it’s mine):

https://github.com/bokwoon95/sq

I feel some exasperation when I see query builders that throw a query string back to the user and ask them to map the results themselves. That’s easily the most tedious and mistake-prone part of using SQL queries. In the case of my library, projection and mapping are handled by the same callback function so in order to SELECT a field you basically map it and it’s automatically added to the SELECT clause.

Re: Ent: An Entity Framework for Go

#25

Post by spion »

jitl wrote: post #17
valenterry wrote: post #7

Earlier quoted context omitted.

> 1. Codegen is powerful, and often easier to understand than a mountain of typelevel magic. I disagree here. And I also don't like your framing. Yes, type-level logic is harder to learn than understanding code you already read everyday. It's also easier to count and calculate with your fingers and use concrete examples rather than learning abstract math. But we still do it, because in the end you learn it once and h…

None of the industrial languages I’ve looked at (Kotlin, Typescript, Go, Java, Swift, Rust) can do the things I want to do using only typelevel features, especially at practical scale. Eg, transform a schema type that describes my database tables into an easy-to-use query builder and data abstraction API with rich method chaining. Often in Java/Kotlin projects people end up writing compiler plugins / annotation proce…

> Eg, transform a schema type that describes my database tables into an easy-to-use query builder and data abstraction API with rich method chaining.

TypeScript can do this. It was done already halfway-well 6 years ago with way fewer features in TypeScript (https://github.com/brianc/node-sql/blob/master/lib/types.d.t...) - today we can do much better.

Re: Ent: An Entity Framework for Go

#26

Post by spion »

spion wrote: post #25
jitl wrote: post #17

Earlier quoted context omitted.

None of the industrial languages I’ve looked at (Kotlin, Typescript, Go, Java, Swift, Rust) can do the things I want to do using only typelevel features, especially at practical scale. Eg, transform a schema type that describes my database tables into an easy-to-use query builder and data abstraction API with rich method chaining. Often in Java/Kotlin projects people end up writing compiler plugins / annotation proce…

> Eg, transform a schema type that describes my database tables into an easy-to-use query builder and data abstraction API with rich method chaining. TypeScript can do this. It was done already halfway-well 6 years ago with way fewer features in TypeScript ( https://github.com/brianc/node-sql/blob/master/lib/types.d.t... ) - today we can do much better.

FWIW I've given up the SQL query builder route and instead went with GraphQL query builder / Hasura route (https://typed-graphql-builder.spion.dev/).

Its technically codegen but only from the schema; queries are fully typed on-the-fly.

Re: Ent: An Entity Framework for Go

#27

Post by impulser_ »

valenterry wrote: post #5

> 100% statically typed and explicit API using code generation. Whenever I have to do code generation in my language of choice, I feel that the language should be able to do that without having to generate code. It's annoying to inspect and maintain and usually has quirks that I have to work around. How do Go developers feel about that?

Code generation is feature of Go. We use it with ent to generate clients, services, and database all together using the same ent scheme.

We even use it to generate clients and servers for other languages with the help of templates.

The language is small and simple that maintaining the generated code isn't that big of a problem as you might think.

Re: Ent: An Entity Framework for Go

#28

Post by spion »

jitl wrote: post #13
rowanG077 wrote: post #9

Earlier quoted context omitted.

Totally agree with you. Especially about point 1. Codegen is one of the bluntest tools there is and should be almost always avoided.

Why is that? I’ve done a few toy attempts to build out ORM-like model classes in Typescript that wrap an input schema type using typelevel features, and my profiles of the Typescript compiler show a lot of slowdowns coming from combinatoric explosions in the typechecker. In this language specifically, the type system has quite advanced expressiveness but using those features in practice runs into limitations of the c…

While in that specific case codegen does sound like the right approach, I think in most regular cases you would be able to get away without it. Honestly, a 64-variant type is not really that common.

I think codegen is OK as long as

- its designed in a way where it doesn't cause users to want or need to modify the generated code (this is the biggest downside of codegen)

- its against "relatively stable" API thing (protobuf / swagger descriptions, DB schema etc).

Re: Ent: An Entity Framework for Go

#29

Post by Fire-Dragon-DoL »

bokwoon wrote: post #24
Fire-Dragon-DoL wrote: post #4

Earlier quoted context omitted.

I keep thinking that the query portion should be entirely split from the ORM portion. Query builder have specific usage, but are not the norm. None of them can model an advanced postgres query, but at the same time, they provide little (or nothing) utilities to map the data coming from a complex query, back to objects, which is funny, to me that would be the definition of "object relational mapper". I know why active…

> at the same time, they provide little (or nothing) utilities to map the data coming from a complex query, back to objects Example of a query builder with built-in mapping capabilities (it’s mine): https://github.com/bokwoon95/sq I feel some exasperation when I see query builders that throw a query string back to the user and ask them to map the results themselves. That’s easily the most tedious and mistake-prone pa…

I skim-read it but couldn't find an example of what I think as challenging: a join of 3 tables (well, even two).

When you join 3 tables (assuming has many and "has many through" relationships), what you get back is enormous rows and multiple rows, all of this in tabular form, but in the software is usually represented as a graph. I'd love a library that helps building back these massive rows into relationships.

Please forgive me if your library does this, while I saw the "mapping function", I didn't see anything to help me build back graphs. I can map rows "easily", but I cannot recreate associations easily, it requires a bunch of work.

Re: Ent: An Entity Framework for Go

#30

Post by jitl »

spion wrote: post #25
jitl wrote: post #17

Earlier quoted context omitted.

None of the industrial languages I’ve looked at (Kotlin, Typescript, Go, Java, Swift, Rust) can do the things I want to do using only typelevel features, especially at practical scale. Eg, transform a schema type that describes my database tables into an easy-to-use query builder and data abstraction API with rich method chaining. Often in Java/Kotlin projects people end up writing compiler plugins / annotation proce…

> Eg, transform a schema type that describes my database tables into an easy-to-use query builder and data abstraction API with rich method chaining. TypeScript can do this. It was done already halfway-well 6 years ago with way fewer features in TypeScript ( https://github.com/brianc/node-sql/blob/master/lib/types.d.t... ) - today we can do much better.

I want to derive a Model type with methods from a Row type so I can write something like `const openDiscussions = blockModel.getContent({ where: c => c.getType() !== “page” }).andRecurse().getDiscussions({ where: d => !d.getResolvedAt() })` given an input row type like `type BlockRow = { id: BlockId, type: “page” | “text”, content?: BlockId[], discussions?: DiscussionId[] }; type DiscussionRow = { id: DiscussionId, resolvedAt?: Date }`
Post reply on HN