potygen VS TypeORM

OMG this is one of my favorite tools paid for it all the way back when it went out. Have used it so many times just to write documentation for things like:

https://github.com/ivank/potygen/blob/main/packages/potygen/...

ASCII is just so versatile and allows you to put nice graphics in places where one does not expect, making things more easily understandable.

I also wrote a parser (in typescript) for postgres (https://github.com/ivank/potygen), and it turned out quite the educational experience - Learned _a lot_ about the intricacies of SQL, and how to build parsers in general.

Turned out in webdev there are a lot of instances where you actually want a parser - legacy places where they used to save things in plane text for example, and I started seeing the pattern everywhere.

Where I would have reached for some monstrosity of a regex to solve this, now I just whip out a recursive decent parser and call it a day, takes surprisingly small amount of code! (https://github.com/dmaevsky/rd-parse)

I used to agree 100% with this sentiment, as dissatisfaction with available ORMs at the time (early days of doctrine in PHP) drove me to actually write my own. Turned out an amazing exercise in why orms are hard.

Anyway a few years later I was in a position to start things fresh with a new project so thought to myself, great lets try to do things right this time - so went all the way in the other direction - raw sql everywhere, with some great sql analyzer lib (https://github.com/ivank/potygen) that would strictly type and format with prettier all the queries - kinda plugged all the possible disadvantages of raw query usage and was a breeze to work with … for me.

What I learned was that ORMs have other purposes - they kinda force you to think about the data model (even if giving you fewer tools to do so) With the amount of docs and tutorials out there it allows even junior members of the team to feel confident about building the system. I’m pretty used to sql, and thinking in it and its abstractions is easy for me, but its a skill a lot of modern devs have not acquired with all of our document dbs and orms so it was really hard on them to switch from thinking in objects and the few ways orms allows you to link them, to thinking in tables and the vast amounts of operations and dependencies you can build with them. Indexable json fields, views, CTEs, window functions all that on top of the usual relation theory … it was quite a lot to learn.

And the thing is while you can solve a lot of problems with raw sql, orms usually have plugins and extensions that solve common problems, things like soft delete, i18n, logs and audit, etc. Its easy even if its far from simple. With raw sql you have to deal with all that yourself, and while it can be done and done cleanly, still require intuition about performance characteristics that a lot of new devs just don’t possess yet. You need to be an sql expert to solve those in a reasonable manner m, just an average dev could easily string along a few plugins and call it a day. Would it have great performance? Probably not. Would it hold some future pitfalls because they did not understand the underlying sql? Absolutely! But hay it will work, at least for a while. And to be fair they would easily do those mistakes with raw sql as well, but with far few resources to understand why it would fail, because orms fail in predictable ways and there is usually tons of relevant blog posts and such about how to fix it.

It just allows for an better learning curve - learn a bit, build, fail, learn more, fix, repeat. Whereas raw sql requires a big upfront “learn” cost, while still going through the “fail” step more often than not.

Now I’m trying out a fp query builder / ORM - elixir’s ecto with the hopes that it gives me the best of both worlds … time will tell.

If you use Sequalize, TypeORM or for MongoDB, we have Mongoose these types of ORM tools, then you are safe by default because these help us against the SQL query injection attacks by default.

We decided to use MySQL for a database. and TypeOrm for ORM. The ER diagram is provided below. For example, the task_assignments table holds information about user assignments to tasks. While in DDD, there is a pattern to design denormalized tables that reflect the structure of domain objects more directly, but this time, a more conventional table design was chosen. TypeOrm models:

How does this compare to using directly an ORM lib that supports browser like TypeORM [0] via SQL.js [1]?

[0] https://typeorm.io/

* Patch a third-party library that was setting an HTTP header to `null`. NodeJS handles this case just fine, but Deno throws an error [2].

After all of that work, I finally was able to use Deno in my project. It was really cool! Unfortunately, both VS Code and IntelliJ with Deno are essentially unusable [3]. Or, at least, unacceptably slow compared to what I had with NodeJS.

[0]: https://stackoverflow.com/a/66073607

[1]: https://github.com/typeorm/typeorm/issues/6123#issuecomment-...

[2]: https://github.com/Sansossio/twisted/issues/97

[3]: https://github.com/denoland/vscode_deno/issues/895

TypeORM is a very convenient ORM for JS apps. We use it with NestJS and running it on NodeJS.

We are going to start using TypeORM as an ORM to help us interact with Postgres, but we also have an example of using Prisma in the future and everything that we have to adapt to switch the ORMs if necessary. At the end we are implementing neon.tech as a production database, right? 😉

TypeORM is a popular Object-Relational Mapping (ORM) library for Node.js. It provides a high-level abstraction over relational databases, making it easy to perform CRUD (Create, Read, Update, Delete) operations.

TypeORM places its focus on TypeScript and JavaScript (ES7+) development. It offers compatibility with various database systems, including MySQL, PostgreSQL, SQLite, and MongoDB. What sets TypeORM apart is its robust integration with TypeScript. It provides a user-friendly experience with a convenient decorator-based syntax for defining entities and relationships. Additionally, TypeORM supports the repository pattern and enables eager loading, enhancing its versatility for developers.

ᴬ typeorm officially supports mssql@v9, but the support for the custom stream builder was added in mssql@v10. Since mssql is a peer dependency of typeorm, you can force override it and use the Cloud SQL Connector with typeorm. There is an open PR to add support for mssql@v10 in typeorm.