ts-sql VS TypeORM

There is an implementation of SQL that operates on a table shaped type, entirely at type level. For your amusement: https://github.com/codemix/ts-sql

There are a bunch of more practical takes that codegen types from your database and generate types for your queries, eg: https://github.com/adelsz/pgtyped

To me the second approach seems much more pragmatic because you don’t need to run a SQL parser in a fairly potato interpreter on every build

> If I would level criticisms at dialyzer it would be its sometimes difficult to read warnings, it’s speed (despite being multithreaded) and the race conditions in the VS Code plugin (which is looking for extra maintainers – if I had time I would help).

One of the advantages of TypeScript is that VSCode is written in TypeScript, and both VSCode and TypeScript are developed by the same company, so there's a really nice synergy there. I imagine Kotlin users feel the same way using Jetbrains products, and Swift users feel the same way about XCode.

Dialyzer looks interesting, but I can't imagine giving up on the expressiveness of TypeScript. Some of the things you can do with generics, mapped types, intersection types, template literal types, conditional types, and utility types are almost mind boggling. It's difficult to reap all of the benefits of static analysis without some of these advanced type operators. The type manipulation section of the TS manual is really underrated.

Someone for example wrote an SQL parser in TypeScript that requires no runtime code [1]. It can infer the types of an SQL query's result based on an SQL string without any runtime code execution. There was a similar project where someone built a JSON parser entirely using the type system [2]. There's also an ongoing discussion on Github about the the fact that TypeScript's type system appears to be a Turing-complete language with some other cool examples [3]. My point is that the type system is incredibly expressive. You rarely run into an idiom that can't be typed effectively.

[1] https://github.com/codemix/ts-sql

[2] https://twitter.com/buildsghost/status/1301976526603206657

[3] https://github.com/microsoft/TypeScript/issues/14833

If anyone saw this meme and thought, "damn parsing a type from a SQL query, that looks useful" (as I did), the source appears to be from here.

I mean, why stop there? https://github.com/codemix/ts-sql

Which allows for things like this type that implements a simplified SQL query parser checked against a provided 'database' object:

https://github.com/codemix/ts-sql

This project was my go-to "nifty but pointless" example for TS string literal types before this article :)

author of ts-sql[0] here, this looks great (and a way more practical approach!)

[0] https://github.com/codemix/ts-sql

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.