domain-driven-hexagon

domain-driven-hexagon copied to clipboard

@slonik/migrator is not compatible with slonik 30+, so you cannot create a migration.

To reproduce just delete node_modules folder and try to npm install packages.

You have to force it npm install --force and it should work, this is a workaround for now until @slonik/migrator updates the package (or until I replace it for something else).

@Sairyss what do you think of typeorm? Maybe I can help you switch from slonik to it

This project was using TypeOrm before slonik. ORMs are generally not very flexible and performant for big applications so I prefer using raw queries instead. This is discussed briefly at the end of Persistence models section.

@Sairyss Indeed, thank you. Do you know any worthy alternatives to slonik?

Not really. If you want raw queries you either use pg, which is very barebones, or Slonik that offers some nice extra features on top. Alternatively you can use a query builder, there are couple of options here:

• knex is a standard for some time now
• kysely is an emerging star nowadays

But I'm not a big fan of query builders tbh so I prefer raw queries.

Although if your project is not very complex, using an ORM instead is totally fine. You could even use both options and combine power of ORM for types, migrations, easy inserts, simple queries, etc. and use raw queries when you need performance/flexibility. All depends on the project.

Thanks for the answer

I also prefer slonik to ORMs. Due to the poor state of affairs with slonik migration libraries, I have used knex strictly for migrations while using slonik for all application queries, and this has worked well. It might create some ambiguity for new devs because knex implies that the application code makes use of it as an ORM. Adding something to the README seems an easy enough way to resolve this confusion, though. Maybe something to consider for this repository since the need to use --force for the npm install is not obvious and hurts what is otherwise a very polished setup experience.

First of all, thank you @Sairyss for the immense work you have done in this repo. I started reading the issue related to the one discussed here in the @slonik/migrator repo https://github.com/mmkal/slonik-tools/issues/417

I have never used slonik, but from what I read there are two aspects that stand out although I really like it and agree that for a large project a raw query approach could be preferable:

• The project appears to be managed by only one person.
• The project had gone several major changes in the same year (and thats why slonik-tools is not updated yet) .

Don't you think it would be problematic in a large and complex project, in the long term, relying for the DB layer, on a library managed by a single person and which often introduces major changes based mostly on the opinion of himself ? Would you make the same choice and pick slonik for a new project even today?

@marcoturi Yeah, breaking changes is definitely an issue. Though slonik is a pretty minimal wrapper, you could create your own or fork it. In one of my projects, way before I found out about slonik, I created my own lib similar to slonik (though somewhat simplified). It took me about a couple of days and still works fine to this day.

If I had to choose what to use today, I would probably fork slonik and remove all unnecessary bloat from it, adapt it to my needs, and use that.