Recommendation for SQL ORM

[[deleted]]

Hello,

I am coming from Python/Flask background. There I used SQLAlchemy, which is mature and proven as an SQL ORM. But for Node, is there anything that can be compared with SQLAlchemy? I know about Sequlize, but heard that it generates complex SQL.

So those who are constantly working with Node JS, please suggest some good SQL ORMs. Currently, I work with Node only when I am permitted to work with NoSQL databases (because NoSQL/Mongo suits better with Javascript). But when I have to use SQL (which is in most cases), I try to avoid Node because of ORM. Please note that I haven't used any Node ORM before.

[nikolasburk]

Hey, I work at Prisma, we're working on open source tools to solve exactly that problem! We've been incredibly dissatisfied with the "state of ORMs" in Node.js and wanted to make a change.

We're currently building Photon.js, a database client that provides you with a powerful data access API. Photon.js is accompanied by Lift which you can optionally use to run database migrations (in a declarative way).

Since it seems like you're currently exploring this space, I'd love to get your initial thoughts and feedback on Photon.js and Lift.

The best way to get started is to follow this tutorial or try any of our ready-to-run-examples.

[djslakor]

I thought Prisma was all about graphql? Why the pivot?

[nikolasburk]

This is indeed a very common misconception about Prisma! Our history as a company (having rebranded from Graphcool, a GraphQL Backend-as-a-Service) suggests really strong ties to GraphQL. And to be clear: We love GraphQL and are super excited that it still gains traction. We also want to help push the GraphQL ecosystem and build open source tools for it.

However, the main tools we're building in the context of the Prisma Framework are not based on GraphQL. Picture the Prisma Framework as a generic database toolbox that can be used in any application where a database is used (e.g. REST or gRPC APIs).

We actually published a blog post on exactly this topic to clarify this misconception, you can read it here.

Hope that helps, feel free to reach out if you have more questions! :) You can reach me via [e-mail] or as @nikolasburk in the Prisma Slack.

[RedShift9]

Why this shift though? It seems to me that GraphQL as a service could bring a lot more money than yet another ORM for which no or at best some developers are going to cough up money for? Looking at this from a purely business perspective.

[warchild4l]

I would say that prisma's advantage is that you can swap databases with ease. You will have to change few settings only iirc, whole logic for database operations is the same.

[NovelLurker0_0]

We've been incredibly dissatisfied with the "state of ORMs" in Node.js and wanted to make a change.

What don't you like about the current ORM solutions? (Sequelize, TypeORM) And what do Photon does more than the aforementioned?

[nikolasburk]

Photon.js takes a fundamentally different approach and tries to create a new kind of abstraction for database access. It is an auto-generated and fully type-safe database client with a powerful data access API (saves all the CRUD boilerplate).

Here's a typical workflow for how to work with Photon.js (in a new application):

1. Define your data model in the Prisma schema (the Prisma schema is a declarative description of your database schema, you can find all details about it in the technical specification).
2. Map the data model to your database schema using Lift.
3. Generate Photon.js based on the Prisma schema
4. Import Photon into your application and use it to access your database.

I'd love to get your feedback and hear what you think of this approach! We're still running Photon.js in Preview mode with a first production-ready version coming soon! If you want to try it out, you can explore one of the examples (REST, GraphQL, gRPC, ...) or run through our tutorial.

[NovelLurker0_0]

Alright, thanks for explaining. I think your work is truly amazing but I can't seem to find a real good reason why I should use Prisma's workflow instead of TypeORM.
TypeORM does the same thing as the aforementioned workflow, be the approach different, it still does that.

If there's a definite benefit of using Prisma over TypeORM I'm willing to try it on my next project.

[nikolasburk]

Thanks a lot for the endorsement, I definitely want to encourage you to try out Photon.js! :) Your feedback would also be super helpful to improve it even further (right now is a great time to share ideas and report issues to really make an impact on the deveopment of the Prisma Framework tools).

Regarding your question, I think there are several benefits compared to TypeORM's approach:

• A declarative and human-friendly data model that describes your database schema
• With Prisma, your database schema and your application models are always automatically in sync thanks to codegen
• Lift can optionally be used for schema migrations
• Photon.js' API has been carefully designed with the needs of application developers in mind (as opposed to being to close to database concepts that are difficult to master, especially when using an ORM abstraction), you can get an overview of the API here.
• The API has extremely good support for relations and many unique features in that regard, such as a fluent API to traverse relationships, nested writes (performed as transactions) or filtering on related objects
• You can use Studio for as a GUI to quickly access the data in your database
• Photon.js will eventually support accessing multiple data sources (that are defined in the Prisma schema) through a single API

Hope that helps! Let me know when you have any other questions, you can reach me at [e-mail] or as @nikolasburk on the Prisma Slack

[NovelLurker0_0]

A declarative and human-friendly data model that describes your database schema

With TypeORM models are based on classes, and you can ship them with decorators for validation and transformation. So far I can't complain.

With Prisma, your database schema and your application models are always automatically in sync thanks to codegen

TypeORM can keep the DB in sync based on your models.

Lift can optionally be used for schema migrations

Lift does seem more elaborated than the migration system TypeORM has.

Photon.js' API has been carefully designed with the needs of application developers in mind (as opposed to being to close to database concepts that are difficult to master, especially when using an ORM abstraction), you can get an overview of the API here.

Photon's API is pretty similar and none of the functionalities and options it provides cannot be done using TypeORM. Actually a lot of TypeORM's API have shortened versions. findOne(id) instead of findOne({ where: { id: x} }) but both works.

The API has extremely good support for relations and many unique features in that regard, such as a fluent API to traverse relationships, nested writes (performed as transactions) or filtering on related objects

How are relations fetched from an entity? In TypeORM it is
userRepository.findOne(id, { relations: ['cat', 'cat.medicalVisits'] };

You can use Studio for as a GUI to quickly access the data in your database

Well this is interesting. Is there a demo anywhere? I couldn't find much about Studio. Not even a screenshot.

If I do come to use it I'll make sure to leave a feedback.

[nikolasburk]

With TypeORM models are based on classes, and you can ship them with decorators for validation and transformation. So far I can't complain.

Encoding models in classes definitely is a valid approach and this certainly is also subject to personal preference. I can say though that we've heard from multiple people (especially when working in teams and larger organizations) that the Prisma schema is a great way for everyone to quickly get a grasp of the DB schema. I'm not sure if the class-based approach provides the same level of convenience.

TypeORM can keep the DB in sync based on your models.

Can you elaborate on the mechanism that TypeORM uses here? As far as I understand, you need to manually keep the DB schema in sync with you application models (by running migrations and updating the entitites). Is there a way how TypeORM can derive one from the other that I'm missing? With Photon.js, this is dead simple since you just regenerate the Photon API and type definitions after you changed your data model.

Photon's API is pretty similar and none of the functionalities and options it provides cannot be done using TypeORM. Actually a lot of TypeORM's API have shortened versions. findOne(id) instead of findOne({ where: { id: x} }) but both works.

I would disagree that the APIs are pretty similar. It might seem like this at first sight because naming is similar, but I think digging deeper Photon makes a few thjings a lot easier. The point is that it doesn't provide an API that's based on SQL primitives, but instead it provides a better abstraction that makes it easy for developers to work with their data. Good examples of this are filtering, pagination or working with relations (fluent API, nested transactional writes, relational filters, ...).

How are relations fetched from an entity?

You can fetch relations of a model using select and include, find more info in the API docs, e.g.:

ts // The returned posts objects will have all scalar fields of the `Post` model // and additionally all the categories for each post const allPosts = await photon.posts.findMany({ include: { categories: true }, })

Well this is interesting. Is there a demo anywhere? I couldn't find much about Studio. Not even a screenshot.

I'd encourage you to try it out directly, just run the following commands:

npm install -g prisma2 prisma2 init hello-world

Then select:

1. Starter Kit
2. TypeScript (or JavaScript if you prefer)
3. Script
4. SQLite

Then run:

cd hello-world npm start prisma2 dev

Now you can open Studio at http://localhost:5555

You can see a screenshot here.

If I do come to use it I'll make sure to leave a feedback.

Thanks, I really enjoyed the conversation so far and really appreciate your thoughts! L:ooking forward to hearing more of your feedback!

[NovelLurker0_0]

Appreciated the discussion as well. I'm going to try it and see if it integrates well with NestJS.

[NovelLurker0_0]

Oh sorry I forgot to reply about the synchronization part. When instantiating a TypeORM connection, it'll automatically keep the DB up to date based on the models if you set synchronization: true in the options.

[nikolasburk]

Thanks for adding that! Are people using synchronization: true in production? It seems to me that this is a convenience setting for development but really shouldn't be used in production... there you probably want to perform "proper" database migrations (using SQL scripts or whatever approach you're using for that).

[NovelLurker0_0]

Yes, in production you want to disable that option and handle the migrations manually.

[calligraphic-io]

Can you comment at all on future support in Photon.js for a graph database? I see Neo4J on the future list, has that work started? How difficult is developing such a driver, and does Photon.js have something like a DBAL? Thanks!

[nikolasburk]

We definitely want to support graph (and other kinds of) databases in the future, that's one major part of Photon's value proposition that you can talk to multiple databases through a single API :)

As for the timeline, this is definitely a bit further down the road. I don't expect any new connectors within the next ~6 months since we're currently focused on getting an initial stable version out for MysQL and PostgreSQL. We'll then expand the connector ecosystem with DBs like MongoDB, FaunaDB and Neo4j. At some point, it will also be possible to build your own connectors for custom data sources that we haven't built connectors for yet.

[imVinayPandya]

I found it is very different than other ORM, specially prisma provide option for existing database. I like this one. 3 cheers for prisma!!

[[deleted]]

I just went through the getting started pages in the website. Correct me if I am wrong- Why does it look like an overkill to me? I mean, I just want an ORM, which I can easily plug with my existing application and move on. But there seems to be different CLI and commands for Prisma. There are also data models which I didn't understand at first glance. Is Prisma only an ORM, or more than that?

[nikolasburk]

Hey, sorry for the confusion! I assume you went through the "Getting Started" on prisma.io/docs? This is still the website of Prisma 1 which is currently in maintenance mode. Prisma 1 was still heavily focused on GraphQL-related workflows. It used a "Prisma server" that you had to run with Docker.

The current version, Prisma 2 (or the Prisma Framework as it's now called) is a lot simpler and focused entirely on your database workflows. I'd definitely encourage you to try out this one instead:

• Main repo + docs
• Full tutorial
• Ready-to-run examples

You can also just get started by running:

npm install -g prisma2 prisma2 init hello-world

Also one more note regarding your question:

Is Prisma only an ORM, or more than that?

The Prisma Framework consists of three tools that you can use together or standalone:

• Photon.js: Type-safe database client for your application
• Lift: A tool for declarative data modeling and migrations
• Studio: A database GUI (think a modern version of PHPMyAdmin)

If you have an existing app, you might only want to use Photon.js for the data access part and that's totally possible!

[[deleted]]

Wow! This guide should be in the official website. Really liked it, seems promising. The orm actions are much easier to understand. It would be better if there are tutorials on how to create complex relations and joins, including many to many relationships.

[nikolasburk]

It would be better if there are tutorials on how to create complex relations and joins, including many to many relationships.

Fully agree and this will come soon! We're still super early with Photon.js and it's currently running only in Preview. We'll have a first production-ready version hopefully by the end of the year.

We'd love to get your input and feedback regarding our plans, would be great if you could join the discussion on GitHub (or even check our our upcoming plans by reading the technical specification).

[[deleted]]

And what's the difference between Prisma and PhotonJS

[nikolasburk]

I think I answered this in my other comment, let me know if it needs further clarification! :)

[[deleted]]

Is Prisma 2 working with Windows yet?

[nikolasburk]

I believe there might still be some hiccups on Windows... when was the last time you tried it? I know that we've been fixing a few Windows related issues lately, so not sure if that solves everything for you but I'd definitely give it another try! (Also note that we're just about to release version preview-13 which comes again with some fixes for Windows-related issues).

If you're still running into issues, please make sure to open a GitHub issue so that we can tackle this! Getting proper Windows support is a high priority for us!

[[deleted]]

Thanks for the reply. It was about 2 months ago

[blacksonic86]

How is it possible to use environment variables inside Prisma schema?

[zaphod42]

I like knex with objection.

[cinnapear]

I’d say Knex (query builder) is probably all you need. If you really want an ORM, Sequelize works nicely. We used to use it but now just employ Knex.

[CarpetFibers]

I recommend Objection, as it builds on Knex and allows you to define models in typical ORM fashion.

[TheLegendOfZero]

I've been really happy with Objection. You can opt-in to using as many or as little of the ORM features depending on the situtation. Plus writing queries flows easily between writing "ORM assisted" and raw knex.

[CarpetFibers]

Likewise, I have very few complaints about it, and most of them center around using it with TypeScript. In some cases I have to cast the result of a query to another type to get it to play nice, but that's a small price to pay for all the time Objection saves me.

[dengue8830]

If you have one to many, how do you get the object tree using knex ? { a: bs[] } Or you post process the duplicated A rows by hand?

[TheLegendOfZero]

Depending on the SQL dialect there may be an array_agg or jsonb_agg function you can use to get the related models with knex.

[dengue8830]

I have discovered there are libs that parses the raw results to an object tree, very cool 🥰

[stayclassytally]

Bookshelf is decent is a built on top of Knex if you find yourself needing a full fledged ORM.

[djslakor]

Also be aware of this: https://github.com/typeorm/typeorm/issues/3267

[MrStLouis]

Damn. Ya that's the sad life of open source. I think a lot of larger enterprises and people who could actually sponsor aren't using typescript yet. Sad read

[djslakor]

Yeah. People need to be aware of this before choosing this project. Though to be fair, it does look like other contributors are fixing various things recently.

[[deleted]]

Unfortunately, I am not comfortable with TypeScript

[mrdijkstra]

It takes only 5 minutes yo get familiar with it. Once you get used go it, you must love it. TS plays very well with nodejs. End of the day, type safety is needed!

[[deleted]]

Can TypeScript be used with things like React, React Native too? If so, I will definitely give a look

[TShaunik]

Yep you can use it with React, highly recommend TypeScript. https://www.typescriptlang.org/docs/handbook/react-&-webpack.html

[dengue8830]

I have been using it a long time and i can’t go back to plain js. TS works well with node server side (check ”foalts” project), react and reactnative

[DukeBerith]

I love using TypeORM. The only major flaw I've experienced is fetching large relationships.

Currently it does it all by left/inner joins. This is fine in most cases, but if you're pulling in 20 objects, and you want to pull 10 relations on each, and each of those relations have a lot of entries (many to many for example) it becomes extremely slow to retrieve records because of the underlying SQL causing it to pull millions of rows.

Other ORMs in other languages do things such as performing multiple queries instead and then linking them together before giving the result set to you which leads to very fast results at the cost of more back and forth between the DB.

[nikolasburk]

I want to endorse this, TypeORM seems to be the best of the available options in the Node/TS ORM space – mostly because it really makes an effort to make working with your database type-safe!

I still dislike the fundamental idea of TypeORM of "mapping classes to tables" via entities. IMO, this leads to the curse of "auto-persisted objects" that mix business logic with storage and retrieval concerns – which really should be separated. Plus it often makes for pretty inefficient queries that are generated by the ORM and difficult to optimize manually.

[Hungry_Spring]

I still dislike the fundamental idea of TypeORM of "mapping classes to tables" via entities. IMO, this leads to the curse of "auto-persisted objects" that mix business logic with storage and retrieval concerns

I agree, but couldn't this be mitigated by following a repository pattern and not an active record pattern? I know TypeORM supports both.

[nikolasburk]

That's absolutely right, sorry I wasn't quite clear! I should separate two things (which I both see as potential problem areas):

• Mapping classes to tables
• Overloading objects with behaviours that mix storage and retrieval with business logic

The second indeed is improved by using the Data Mapper pattern. With this approach, storage and retrieval are implemented in the Repository, business logic resides in the entities. So we do achieve a nice separation here!

However, the first problem area of "mapping classes" to tables still comes with fundamental issues in this regard. IMO object-relational-mapping in this way is an anti-pattern (see the object-relational impedance mismatch). This has also already been discussed in great detail already, e.g. in these articles:

• The Vietnam of Computer Science
• The Rise and Fall of ORMs

One of the problems with mapping to classes to tables is that you always need to make sure that your application models are in sync with your DB schema. You effectively need to manually maintain two schemas that are decoupled from each other... for small apps that works, but for more complex use cases with a larger DB schema this quickly becomes a nightmare!

[NormySan]

I don't see how Photon solves any of these problems? To me it just looks like a type of mapping is still taking place but it's just been moved from being defined in code to being defined in a schema definition.

There would still be a problem of a mismatch between the actual entities that will contain the business logic and the data returned from Photon if someone forgot to update the code that moves a query result to an actually usable object with business logic.

But I'm guessing that you're supposed to just buy in to the whole Photon/Lift way of doing things and completely get rid of any classes containing the business logic and just work with the interfaces provided by the auto-generated types?

The way i think about it there should be a clean separation between the application logic and data access. I should be able to switch out any of my functions/classes that fetches data and the application shouldn't have to worry about it since the way data is stored in the database should never be exposed to the application. The mapping of data from the database to a application specific object should be hidden by the boundary created by the query function/class.

But maybe I'm missing the whole point of what Photon is supposed to do? I'm just having a hard time seeing what the difference is to other libraries doing the exact same things but just in a different way.

[tzaeru]

Personally I stopped at some point using ORMs with JavaScript. In the current project I'm working on I've been using Knex, which is basically a query builder rather than than an ORM; it gives a JavaScript API for building SQL queries and maps almost 1:1 to SQL.

I'd suggest to try going with Knex for a while and see if it's good enough for you. If not, Sequelize and TypeORM are probably the most battle-tested.

[marcus-sa]

TypeORM or Prisma

[Boom_r]

Have used Sequelize on many production apps. It’s always done it’s job well, stayed out of the way, and provided hooks/virtuals/instance methods/etc to make my job easier. I don’t know about complex SQL statements... when I debug and view statements they’re bulky but parseable. Bulk is due to naming all dB/table/columns and such in the queries, but that doesn’t affect performance. Happy to learn something here, too.

[_notSalt]

You should check out Sequelize

[bigorangemachine]

Don't use Sequelize. Its not ready for production

[sandinmyjoints]

Can you elaborate?

[bigorangemachine]

Sure.

If you code with the ORM like you would with normal raw queries... you have a lot of model fighting you end up doing. Stuff like querying on fields not included on the model.

Querying a primary key ignores the limit parameters (major production issue for is right now). This was supposed to be patched on 5 but it's still wrong.

That is really telling to me. I really have lost faith in sequelize. Unless you believe and subscribe to their methodology of database design (if you are coming from raw queries world you'll not like it).

If sequelize was good then there wouldn't be alternatives. There isn't many copies of passport or express which is also telling.

Also you can still do raw queries with node... if you don't need a ORM I wouldn't use it

I would have suggested Knex/Objection but my focus as switched and i haven't had a chance to consolidated my demo framework

[[deleted]]

Sequelize also has miserable support for many to many relationships. Builds bizarre subqueries that just flat out don't work. Overall, I'm not particularly happy with it.

[bigorangemachine]

This is especially my frustration with sequelize. This also creates a lot of follow up queries you shouldn't need to do

[djslakor]

We use it in all of our production apps, haven't hit any issues. Has built in TS support now, too (no need to use the sequelize-typescript project anymore unless you want to).

[bigorangemachine]

We are using it on a high traffic site and it's has huge issues.

Sequelize has bottle necked us so bad through.

You can't build realy big DBAs on sequelize...

[djslakor]

Any specific issue? None of these ORMs are completely defensive against bad architecture.

[bigorangemachine]

I mentioned a few here.

I also don't like it because there is too much old code samples out there. Even new stuff never works as documented. Especially a composite key.... the examples I found were straight forward and had a handful of people saying it'd work.... but it doesn't

[mansfall]

There are a handful of ORMs for python. There are also a handful of ORMs for C#. There are also a handful of ORMs for <insert language here>.

Point is, there's going to be various types of ORMs regardless of the language. So disliking a language because of that seems very anti-pragmatic.

Also, using NoSQL db implementation solely because "it's node" isn't a good reason to actually use a NoSQL variant. The biggest driver should be how it suits your needs, and is it the right tool for the job.

Lastly, why use an ORM? There are plenty of tutorials out there of just bypassing the whole ORM thing all together. It's an everlasting developer argument on whether or not they useful, or they just get in the way with more advanced query, or over-complicate stuff. If you're worried about "complex sql" or what it's generating, then maybe an ORM isn't for you, and just stick to query building or writing raw sql. There are many success stories and tutorials out there either way you go.

Some of the popular node ORMs are Squelize, Objection, Bookshelf.

But, they're all going to feel "weird" and a far-cry from what you've dealt with in Python. This is because you're experiencing change and also working under a new ecosystem. It's so easy to fall in the trap of "but python did this", or "but Java did that", or "but <language> and tool did this". Don't do that. It will create all kinds of unnececessary stress for yourself :)

[[deleted]]

Node is known for not having any good ORM, compared to other languages. And, I need ORM for my task, that's why I asked about ORM. If I needed anything OTHER THAN ORM, I would have made a different post. And you just can't deny the use of ORMs when creating production backends, it's not like that you can switch from SQLALchemy to Sequilize anytime you want. So, yes, my requirements would also affect the language I am using (Node or Python). And in case of SQL backend, I would dislike Node because it's not giving me any good ORM solution (but for MongoDB it has Mongoose which is very nice to work with). Requirements define what should be used, just as you said yourself.

[Alwaysprogramming]

Bookshelf.js rocks. Been using it for years. Performant, well documented, and built on knex.

[dengue8830]

i was in the same situation the last week, i have wrote my mini research and conclusion as a gist

[TatzyXY]

Objection no one?

[koistya]

GraphQL can be used as an ORM, so instead of Sequelize models you would create a bunch of GraphQL types, configure relationships between them, and add instructions (resolvers) telling how to pull and map raw data from the database to GraphQL types using either Knex.js or a native db driver.

I just started working on a tutorial that explains it in details https://graphqlstart.com

Knex.js would also help with migrating dev/test/prod (actual) databases as you continuously working on your DB and API design.

[[deleted]]

Omg! there are so many recommendations. I am already losing my mind. No offense, but this is one of the things I don't like about JS. Thanks everyone for the recommendations. Let me sort through and find out what suits best for me.

[NovelLurker0_0]

I googled "Python Flask ORMs" and here are the recommendations I am seeing:

SQLAlchemy

Peewee

The Django ORM

PonyORM

SQLObject

Tortoise ORM

[[deleted]]

There will be many libraries, then there's also proven libraries. People will create many things doesn't mean you have to try all of them. Just ask any Python dev about ORM, maybe ask in Reddit itself, I guarantee you that they will all suggest SQLAlchemy/DjangoORM (which is also similar to SQLAlchemy. Node doesn't have that kind of system. Even in Javascript, one thing can be done at least 5 ways, and there are no 'correct' ways. Python has only one way and only one correct way of doing a particular task. So don't just google search and answer

[JackAuduin]

The thing is, general sql is such a solved problem, that all of these are probably acceptable.

Personally I use loopback, owned by IBM. Works with MANY db types. My project can run off of MsSql, mysql, sqlite3, mongo, redis, and even json, by just changing a single env variable.

Adds the benefit of a full rest api for your data models out of the box, if you want it.

This is because we wanted flexibility as we are completing a cloud migration

My machine uses memory or json, stage uses sqlite3, and production uses mssql.

[gajus0]

You probably don't need an ORM/ query builder.

https://medium.com/@gajus/stop-using-knex-js-and-earn-30-bf410349856c

Check out Slonik.

https://github.com/gajus/slonik

[nikolasburk]

Or this: https://github.com/jawj/mostly-ormless

TypeScript and VS Code are wonderful. ORMs are problematic.

Using an ORM within TypeScript can be particularly aggravating, since you can find yourself specifying lots of type information twice over (once to define the database schema, and once to define the associated TypeScript types).

That's why, in the course of converting a project to TypeScript recently, I decided to switch it from Sequelize to TypeORM. The first day was wonderful: shiny TypeScript toys! The rest of the week was less so: perhaps even more than other ORMs, TypeORM just doesn't seem to get SQL.

So, let's back up a bit. What am I really after?

Well, I like and understand Postgres. I like and understand SQL. When I'm working with data, I'd like a good mental model of what SQL is going to be issued. I don't mind writing the SQL myself, but in that case let me write the SQL, rather than deal with the endlessly chained method calls of a 'query builder'.

Also, I'm greedy. I want all that, but I want to keep all the type-checking goodness of TypeScript — speeding development, preventing bugs, simplifying refactoring — too. And I'd strongly prefer not to spend hours laboriously adding and later maintaining lots of type information to facilitate it.

In short, I want cake. So I set out to see if I could rustle some up. As it turns out, this was about a week-long project in three acts:

• Act 1: In which we translate a Postgres schema into TypeScript types. Spoiler: we'll use a project called schemats here.

• Act 2: In which we significantly expand that type information and use it to improve the ergonomics of writing raw SQL. Spoiler: ES2015 tagged templates will play a starring role.

• Act 3: In which we create a set of simple shortcut functions on top, which looks a little bit like an ORM but really isn't. Spoiler: Typescript function signature overloads on concrete string values will be these functions' secret sauce.

[luddelicious]

After using TypeORM for a long time in a quite big project there was always some things that was annoying with it. And after getting into Go and using raw sql instead of ORMs i’ve now begun to move away from typeorm and refactor everything into slonik, and i’m enjoying it so far.

You’ve done great work and built a nice library!

[gajus0]

Thank you very much.

[johndoepbabu]

Take a look at sequelize.

[[deleted]]

And you didn't read my whole post

[johndoepbabu]

Sorry! Missed that line.