Create a Node/Express + TypeORM Backend
tgiardina opened this issue · comments
I couldn't find a Node/Express + MySQL example backend. Is anyone aware of one? If not, I'd be happy to take a crack at it. I would bootstrap off the excellent Node/Express + MongoDb example, replacing the Mongo models with Sequelize models (unless someone has a better idea).
Hi @kunwar97,
Package looks cool! Looks like you're using MongoDB, though. Am I missing something?
@tgiardina Ohh sorry, If you're planning Node/Express + MySQL then i would like to contribute
@kunwar97 I'll drop a link to the project as soon as I solidify my stack. In particular, I'm considering using
- TypeScript instead of plain JavaScript (I've been coding in Rust the past six months and have come to really enjoy strong-typed languages)
- Knex instead of Sequelize (I forgot how much I dislike Sequelize and its inconsistent documentation)
@tgiardina I think typeORM will be a better choice. Let me know your thoughts
@kunwar97 I hope TypeORM succeeds, but I'm not willing to bet on it. It is only four years old and has 2k open issues, a six-month runway, and been on life support for the past two years. (You can read more about its state here.) Meanwhile Knex is a few years older and seems far more stable.
I'm not opposed to using an ORM per se, but I really dislike Sequelize and can't find a suitably stable, TypeScript-friendly alternative. After all, there's not much point in developing a template that will be unusable in six months.
Does that make sense? Do you think there's a good stable, TypeScript-friendly ORM out there?
Edit:
After further review, I'm not sure I'll find any ORM or Query Builder that is both TypeScript-friendly and as stable as I want. Indeed, if I were to use Knex, it looks like I'd have to use wrapper packages that make Knex more TypeScript friendly, which means I would be relying on unstable packages anyway. I will look more into TypeScript.
how could I know a particular ORM is typescript friendly?
For instance, ever heard of OpenRecord? I just came across it due to the Active Directory/LDAP side that i needed specifically....dunno if its type script friendly or not.
how could I know a particular ORM is typescript friendly?
I don't have a definitive way of doing this. Presumably every ORM can be coerced into working with TypeScript after all. But some will be easier to use than others. On one end of the spectrum, there's TypeORM, which was built with and for TypeScript. On the other end, there's Sequelize, which will force you to hack together lots of new wrapper classes and types without any guidance (all of their TypeScript documentation is dated as far as I can tell). You can figure out where an ORM lies in all of this by reading its documentation, searching through its community, and trying to build a minimal example. This all takes a few hours, but better to spend the few hours now then 10x that later because you chose poorly.
For instance, ever heard of OpenRecord?
I haven't. I generally try to stay away from smaller packages for two reasons:
- The longer a package has been around and the more widely it is used, the longer it will likely stick around.
- The more widely used a package is, the more people I will be able to communicate and collaborate with easily by using it.
This is all somewhat besides the point of my original question, though.
@kunwar97 and anyone else who is interested,
I should have a good starting point by early next week, if you're still interested in helping! And thanks for the TypeORM tip! I decided to use it!
@tgiardina I totally agree with your points. What I like about TypeORM is its query builder. It is very similar to Laravel Eloquent and one can easily create complex queries without any issues.
On the other hand Sequelize is very good for smaller and straight forward projects. But for large and projects with lot of joins and complex queries, I think Sequelize is not well suited for these.
I have worked with Sequelize (Sequelize-typescript as a wrapper) on many projects and faced these issues. So, I think TypeORM will be a better choice for us.
@tgiardina Please let me know when we can start the project
Here's the repo. The stack is
- TypeScript,
- Express,
- Inversify,
- TypeOrm,
structured roughly as described in this article. The project goals are to:
- Conform to the real world specs,
- Follow the industry standards for OOP, REST APIs, and normalized databases,
- Remain as minimal as possible.
- Provide users with resources (articles, documentation) to help them understand how to build a similar project and why they should make similar engineering decisions,
There will be a natural tension between 2 and 3, which I think will define most of the project's engineering problems. For example, was it a good idea to include Inversify? Goal 2 encouraged me to include it, while Goal 3 made me think I should keep it out. I ended up deciding it was better to include it because I think anyone developing an object-oriented back end should be aware of IoC Containers in general and the Inversify package in particular. But it was a non-trivial decision.
I've written a good amount of code already because I wanted to have a decent understanding of my stack before bringing anyone else in, but none of it is set in stone. Feedback is very welcome!
Hi @tgiardina was occupied in office work, will start working on it from tomorrow.
I would highly, highly recommend objection for this. It has the stability and maturity of knex yet it abstracts away a lot of the low level SQL, has typescript support, has an extremely low issue count, and it is actively maintained
Thanks for the recommendation, @jbolotin. Objection is definitely on my radar. And you are right that it look very well maintained. For this project, I am going to stick with TypeORM though. It is both popular enough and good enough that I think a Real World demo will help a quite a few people.
Hello we are currently moving all work in progress to Github Discussions.
I'll close this issue by now, you can find instruction to open a discussion there : #633
Thanks for your contribution !