Express is a super simple and robust framework for creating REST-style APIs in Node. I've been using it on a major project since late last year and have no complaints. I haven't used Sails, so I can't say much about that, except that I can't imagine anything being easier to use than Express.
I recommend against using Sequelize. It has a very large, inconsistent API and spotty documentation, and after trying it out for a few months I realized that an ORM in JavaScript isn't nearly as useful as an ORM in, say, .NET. If you've got any familiarity with SQL at all, I would recommend using a query builder like Knex.js instead. I switched my codebase entirely from Sequelize to Knex and it only took a week or two, and ended up vastly reducing the number of lines of code in my Node app and the number of SQL queries my program was executing. It also made everything more readable. I know an ORM seems like the easiest way to get up and running (especially if you're coming from a good one in another language), but I suggest taking some time to weigh the alternatives before you commit.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
For when you want a little more than a query tool but less than a full-fledged O/RM, I maintain a data mapper for Node+Postgres. It works by introspecting your schema and building a database API with a fairly robust set of CRUD methods, plus some extra goodies like streamlined document management. If you need to run raw SQL, it treats script files exactly the same as database functions and has the obligatory db.query('something complicated') functionality.
100% agree - I recommend really reviewing whether you actually need an ORM at all. In a big enterprise application, maybe yes you save some time and increase consistency but when you are building anything small to medium size I really think its overkill. You can end up spending a lot of time building out your representations instead of just getting on with the actual task.
For me, ORM is a nice to have - I used it in Sails as it was nicely integrated at the time and my application was in-front of a database with 80 unique entities. However, an ORM can force you down a route of using some pretty crazy population methods or you end up breaking out into native code execution because the ORM can't handle the joins or representations you are trying to achieve. When you start to hit this point, for me I have to start questioning why I'm using an ORM in the first place and the benefits it is giving me.
I think my next project will start without and wait for the pay back to become more apparent before jumping into an ORM.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Express is a super simple and robust framework for creating REST-style APIs in Node. I've been using it on a major project since late last year and have no complaints. I haven't used Sails, so I can't say much about that, except that I can't imagine anything being easier to use than Express.
I recommend against using Sequelize. It has a very large, inconsistent API and spotty documentation, and after trying it out for a few months I realized that an ORM in JavaScript isn't nearly as useful as an ORM in, say, .NET. If you've got any familiarity with SQL at all, I would recommend using a query builder like Knex.js instead. I switched my codebase entirely from Sequelize to Knex and it only took a week or two, and ended up vastly reducing the number of lines of code in my Node app and the number of SQL queries my program was executing. It also made everything more readable. I know an ORM seems like the easiest way to get up and running (especially if you're coming from a good one in another language), but I suggest taking some time to weigh the alternatives before you commit.
For when you want a little more than a query tool but less than a full-fledged O/RM, I maintain a data mapper for Node+Postgres. It works by introspecting your schema and building a database API with a fairly robust set of CRUD methods, plus some extra goodies like streamlined document management. If you need to run raw SQL, it treats script files exactly the same as database functions and has the obligatory
db.query('something complicated')functionality.100% agree - I recommend really reviewing whether you actually need an ORM at all. In a big enterprise application, maybe yes you save some time and increase consistency but when you are building anything small to medium size I really think its overkill. You can end up spending a lot of time building out your representations instead of just getting on with the actual task.
For me, ORM is a nice to have - I used it in Sails as it was nicely integrated at the time and my application was in-front of a database with 80 unique entities. However, an ORM can force you down a route of using some pretty crazy population methods or you end up breaking out into native code execution because the ORM can't handle the joins or representations you are trying to achieve. When you start to hit this point, for me I have to start questioning why I'm using an ORM in the first place and the benefits it is giving me.
I think my next project will start without and wait for the pay back to become more apparent before jumping into an ORM.