Have to say, if you like to do bare metal SQL, using the nice features of Postgres, working with this lib is a total Joy!
No “fancy” and bleeding abstractions like something like Prisma, not convoluted type annotations like other TS libs, no, just plain SQL statements in the best JavaScript way of doing it.
I discovered learning to do Postgres a couple years ago, after getting sick of trying to hack Prisma, tried out several others, and after a couple minutes using this, i knew I wasn’t going back.
I'd love to see a library like ecto (eilxir) for javascript. its easily the best toolkit for working with sql I've ever found. simple, powerful and easy to reason about
the list would merit its own dedicated blog post but to highlight a few nice parts, ecto lets me write sql code in elixir. it does not try to wrap it all into objects but I do get schemas. so for instance I can create a schema `Player` which maps to a table "players"
I can then get them via
```
from(p in Player)
|> where([p], p.id in ^player_ids)
|> select([p], p)
|> Repo.all()
```
need to join with an association?
```
from(p in Player)
|> join([p], s in assoc(p, :scores), as: :score)
|> where([p], p.id in ^player_ids)
|> preload([p, score: s], [score: s])
|> select([p], p)
|> Repo.all()
```
this gets me all players with their scores.
need to get the sum of scores for all players?
```
from(p in Player)
|> join([p], s in assoc(p, :scores), as: :score)
|> where([p], p.id in ^player_ids)
|> select([p], %{
player_id: p.id,
score: sum(score.value)
})
|> group_by([p, score: s], [p.id])
|> Repo.all()
```
as you can see, you can unwind this pretty fast to sql in your head. but you can also let the system just grab the kitchen sink when you jsut need to get somethign working fast. and its all very easy to modify and decuple.
this is hardly exhaustive though, I could spend a day talking about ecto. I spent 8 years developing in nodejs but now I work exclusively in elixir. unless what you're doing is 90% done by existing libraries, its juts a better tool for building highly performant backends.
This is probably great to use, but it also highlights in comparison the beautiful simplicity of SQL. Doing something simple is hard, and SQL is so simple that I think most people find little value to abstractions built on it.
Their migrations tool is proprietary and not open-source. The project is basically an open source bait and switch riding off the edge computing hype (since prisma and other major JS ORMs have poor support for edge environments).
There's One Weird Trick™ in managing joins in this case -- create views that implement the joins and then just treat it as yet another table. Bonus feature is creating a consistent way of working with that relation using native DB tools. ;-)
that works great till your database gets big. Then you will watch your memory use skyrocket to perform joins into that view and it will F@#$@# your shit up. eventually it will take so much time to construct your view table that you'll tiemout your connection pool.
to be clear, dont' use views in production queries. you WILL regret it.
I love layers above sql because it can make a lot of domain logic nice to model. But dropping down when it it makes sense and finding a rock solid foundation is nice too.
<3 Entity Framework Core but also love the new interfaces that let me cast a db connection to Npgsql connection and use its advanced features and raw performance.
It would be great if postgresjs could underpin Knex and MikroOrm.
Yea, it is a totally fan to work with this code after a responsible developer leaves a company. No types, no annotations, no abstractions, no migrations, just plain SQL.
I can't read if you're being snarky or if you are being earnest.
If snarky, is this based on something that actually happened to you? If so, I would love to hear how that actually went about, and what it is you are unable to grasp when things aren't bogged down by complexity?
If earnest, I'm glad more people prefer code that isn't littered with premature abstractions, redundant types, and useless comments expressing what can be more clearly read in the actual code.
No “fancy” and bleeding abstractions like something like Prisma, not convoluted type annotations like other TS libs, no, just plain SQL statements in the best JavaScript way of doing it.
I discovered learning to do Postgres a couple years ago, after getting sick of trying to hack Prisma, tried out several others, and after a couple minutes using this, i knew I wasn’t going back.