TypeORM

Almost every app stores data permanently: usernames, orders, messages. Databases exist for this purpose — programs that store and retrieve large amounts of data in an orderly way. Many databases are operated using their own query language called SQL, which has little in common with the rest of the program code. TypeORM is a tool that bridges this gap. It allows developers to treat data in code like ordinary objects, and generates the matching database commands itself. It is used in projects written in JavaScript or in its stricter variant, TypeScript.

Why developers don’t want to write every query by hand

Without such a tool, you have to formulate SQL text by hand for every data access. This is error-prone, because the text is only checked when it is executed. A typo in a column name might then only be noticed by the user. TypeORM checks such things already during development, because the data structure is described in the code.

There is also the time saved on routine tasks. Creating, changing, searching for, or deleting a record are always the same four patterns. TypeORM provides them ready-made, instead of every team building them anew. In a mid-sized project, this saves hundreds of lines of code.

Another point is the interchangeability of the database. TypeORM communicates with PostgreSQL, MySQL, and SQLite, among others. If a project switches systems, a large part of the code remains unchanged. However, this independence is never complete, because the systems differ in details.

From class to table

The core is a mapping between code and database. The developer writes what is called an entity, i.e., a description of a data type such as “User”. It contains the fields: name, email, date of birth. TypeORM turns this into a table, in which each field is a column and each user is a row.

This mapping is marked with short annotations in the code, the decorators. They sit directly above a field and indicate, for example, that it is the primary key. A primary key is the unique number by which a record is identified. Relationships are also described this way: a user has many orders, an order belongs to a user.

When executing a query, TypeORM builds the SQL command from this and sends it to the database. It converts the response back into objects. This back-and-forth translation gives the whole software category its name: Object-Relational Mapping, or ORM for short. The price for this is a certain loss of control. For complicated queries, an ORM sometimes produces slower SQL code than an experienced developer would write by hand — which is why TypeORM also allows the use of raw SQL.

TypeORM in real projects

The name is encountered mainly in the context of Node.js, i.e., JavaScript on the server. TypeORM appears especially often together with NestJS, a widely used framework for server applications. Anyone reading a job posting for backend development will regularly find TypeORM listed there alongside alternatives such as Prisma or Sequelize.

A typical field of application is the software behind an online shop or a web app. It also lies behind the scenes in AI products: user accounts, billing, and a chatbot's conversation histories are stored in a perfectly ordinary database. The actual language model has nothing to do with this, but without this kind of management there would be no product.

A common misconception is that TypeORM is itself a database. It is not. It is merely the mediating layer between the two, comparable to an interpreter who connects two sides but owns nothing themselves. The data still resides in the database system, which must be installed and operated separately.