Bachelor's and Master's in CS from MIT. Previously, worked @ Microsoft & Zynga. Currently Co-Founder of Moesif (moesif.com), the most advanced API analytics platform.
I think key is coming from Rails world. Rails Ruby world tends to be very opinionated approach to doing this... i.e. "Rails" as the analogy. If you follow the rails standard set of tech stack, all the key tech decisions are already made.
But in Node.JS world, they take a slightly different approach. They intentionally try to be less opinionated. Therefore, there are just about so many options in every layer of the stack.
It can be intimating to try to make so many decisions right at the beginning. But you can do piece meal, and if you play with a library or something, and you don't like it, you can just switch to one of the MANY competing tech/library/tool.
I get the thinking behind it, and totally understand why many folks prefer the almost unix-y approach of small, separated tools, that you can combine as you choose. For me, developer productivity is a key consideration, and having consensus, battle-tested tools like those in the Rails world naturally fosters said productivity. Also makes it really easy to find answers to questions :)
So far, here is the stack I'm playing with, given some recommendations from another developer community:
I also find myself writing lots of cli scripts that rails has built in, such as a console/repl that loads app files, DB creation scripts, DB seed scripts (Knex's built-in seed functionality doesn't work if seed order matters — important for relational data).
Anyway, seeing how spoiled I was in the Rails world :)
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.
I think key is coming from Rails world. Rails Ruby world tends to be very opinionated approach to doing this... i.e. "Rails" as the analogy. If you follow the rails standard set of tech stack, all the key tech decisions are already made.
But in Node.JS world, they take a slightly different approach. They intentionally try to be less opinionated. Therefore, there are just about so many options in every layer of the stack.
It can be intimating to try to make so many decisions right at the beginning. But you can do piece meal, and if you play with a library or something, and you don't like it, you can just switch to one of the MANY competing tech/library/tool.
Yeah, that's kinda what I was worried about :D
I get the thinking behind it, and totally understand why many folks prefer the almost unix-y approach of small, separated tools, that you can combine as you choose. For me, developer productivity is a key consideration, and having consensus, battle-tested tools like those in the Rails world naturally fosters said productivity. Also makes it really easy to find answers to questions :)
So far, here is the stack I'm playing with, given some recommendations from another developer community:
Express + body-parser (JSON API support)
Knex (Database interface)
Knex + knex-migrate (migrations)
Bookshelf (ORM)
pg (PostgreSQL support)
mocha + chai + chai-http (API testing)
morgan (logging)
gulp (task runner)
(Open to suggestions if anyone prefers other tools)
In comparison, the same functionality in Rails looks like this:
rspec + webmock (API testing)
Rails (Everything else)
I also find myself writing lots of cli scripts that rails has built in, such as a console/repl that loads app files, DB creation scripts, DB seed scripts (Knex's built-in seed functionality doesn't work if seed order matters — important for relational data).
Anyway, seeing how spoiled I was in the Rails world :)