3 ms·

Ent. An Entity Framework for Go

39 points by ibraheemdev 6y ago

vvern 6y ago
What I think I've always wanted an ORM in go to look like. Love the way that it declaratively defines schema and then enables client generation.
ivanvanderbyl 6y ago
I've used most of the Go code generated ORMs and would have to say Ent is now my go-to for new projects. It works really nicely with gqlgen, handles permissions, and does eager loading.
- gsempe 6y ago
  I’m very interested to read an exemple mixing ent and gqlgen if by chance you knew an article. Thank you very much
bmo-at 6y ago
Lol. Started development on the API for my new app and was looking for an ORM, found gorm first and then switched to ent just a few days ago. Suddenly it appears on hackernews. I can really recommend it. It's been nothing but a pleasure. Only criticism would be the following: if you have a structure named ent/schema/*.go at the root of your project like they recommend, the code it generates lands in ent/ This isn't always great because it bloats the folder quite a bit. A separate folder for the generated code would be terrific.
- ibraheemdev 6y ago
  How do you find the code generation flow? I would think it would be a bit disconcerting to have to generate tons of code every time you make a change.
jjjeii3 6y ago
Why doesn't GO have a try-catch blocks? Every file I see have dozens similar lines: if err != nil { log.Fatal(err) } In C# I can just log error on one place and transaction will be automatically rolled back. Much less code.
- sketchyj 6y ago
  Go made the design decision to encourage checking for errors where they occur instead of catching exceptions somewhere down the line.
- proyb 6y ago
  There are years of discussion on error handling topics or you could use a package to simplify your code: https://itnext.io/golang-error-handling-best-practice-a36f47b0b94c https://itnext.io/golang-error-handling-best-practice-a36f47...
- ibraheemdev 6y ago
  There have been tons of discussions and proposals regarding error handling boilerplate [0][1], and the general consensus is that go developers like the explicitness of `if err != nil` and just want to leave it be [2] [0]: https://github.com/golang/go/issues/32437 https://github.com/golang/go/issues/32437 [1]: https://github.com/golang/go/issues/32804 https://github.com/golang/go/issues/32804 [2]: https://github.com/golang/go/issues/32825 https://github.com/golang/go/issues/32825

39 points by ibraheemdev 6y ago

What I think I've always wanted an ORM in go to look like. Love the way that it declaratively defines schema and then enables client generation.

ivanvanderbyl 6y ago

I've used most of the Go code generated ORMs and would have to say Ent is now my go-to for new projects. It works really nicely with gqlgen, handles permissions, and does eager loading.

gsempe 6y ago
I’m very interested to read an exemple mixing ent and gqlgen if by chance you knew an article. Thank you very much

bmo-at 6y ago

Lol. Started development on the API for my new app and was looking for an ORM, found gorm first and then switched to ent just a few days ago. Suddenly it appears on hackernews. I can really recommend it. It's been nothing but a pleasure. Only criticism would be the following: if you have a structure named ent/schema/*.go at the root of your project like they recommend, the code it generates lands in ent/ This isn't always great because it bloats the folder quite a bit. A separate folder for the generated code would be terrific.

ibraheemdev 6y ago
How do you find the code generation flow? I would think it would be a bit disconcerting to have to generate tons of code every time you make a change.

jjjeii3 6y ago

Why doesn't GO have a try-catch blocks? Every file I see have dozens similar lines: if err != nil { log.Fatal(err) } In C# I can just log error on one place and transaction will be automatically rolled back. Much less code.

sketchyj 6y ago
Go made the design decision to encourage checking for errors where they occur instead of catching exceptions somewhere down the line.
proyb 6y ago
There are years of discussion on error handling topics or you could use a package to simplify your code: https://itnext.io/golang-error-handling-best-practice-a36f47b0b94c https://itnext.io/golang-error-handling-best-practice-a36f47...
ibraheemdev 6y ago
There have been tons of discussions and proposals regarding error handling boilerplate [0][1], and the general consensus is that go developers like the explicitness of `if err != nil` and just want to leave it be [2] [0]: https://github.com/golang/go/issues/32437 https://github.com/golang/go/issues/32437 [1]: https://github.com/golang/go/issues/32804 https://github.com/golang/go/issues/32804 [2]: https://github.com/golang/go/issues/32825 https://github.com/golang/go/issues/32825