My start-up group is in the process of building our team for our latest project (working title: "Devshare"), so I'd like to take a few minutes to explain the software stack we're designing for future newcomers.
Wait, why Node.js?
Good question! There are a lot of ways to write a web-based software platform. Ruby on Rails seems like the most popular solution for most sites, and I think it is good for most things. It probably would've been a good choice for us, too.
So here are the biggest reason's why I chose Node.js:
- It's just Javascript. I know it well, and chances are you do, too.
- There's no magic. Rails has too much magic (in my opinion).
- It's asynchronous by default, which encourages scalable design.
If you're looking for a more thorough explanation of what's so cool about Node.js in general, see: Why The Hell Would I Use Node.js? A Case-by-Case Introduction
And then there's the fact that I just wanted to learn it for my own reasons, and no one could tell me not to. Freedom of choice is one of the best things about working on your own projects.
Swagger
Node.js has no shortage of frameworks, and I spent weeks evaluating the options, some by reading docs, some by testing. I picked the API framework, Swagger, first. It was almost a no-brainer, as I haven't ever seen a RESTful API framework that is built in a cross-platform, declarative manner. Since a huge part of DevShare is the API itself, I wanted to make it as solid and easy to use as possible, which I've done thanks to swagger-node-express and swagger-ui.
Knex and Bookshelf
Choosing the ORM and database framework was a lot harder. There are a few that I really want to like, but ran into various gotchas with. I wound up choosing Bookshelf (which utilizes Knex) because:
- It's a lot like Backbone.js, which I know and love.
- It supports Sqlite and Postgres.
- Migrations are simple and easy, thanks to Knex.
- Ghost uses it, so it is getting a lot of development right now.
Postgres
This is probably the part that I'm least excited about. Not that there's anything wrong with PG, but I just don't know enough about it yet. Part of me was hoping I could use some NoSQL solution, but I don't yet trust any of them for data integrity as much as an RDBMS. Since Bookshelf supports either MySQL or Postgres for production, that made the DB decision a lot easier. After some research, PG just made sense. Plus, I <3 Heroku and they <3 Postgres, so by the transitive rule, I <3 Postgres.
Heroku
I just feel like time spent administering a web-server is time poorly spent, so I make Heroku do it for me. Other good things about using Heroku:
- Prevents environmental cruft from forming, since the whole project is redeployed from scratch each time, leaving only a few specific environment vars hanging around.
- The server can "scale-up" it's hardware quickly and easily.
- Anyone familiar with Heroku can understand how to deploy the project.
The "front end"
When I'm building a tool for developers, I like to imagine: "What if this hits the front page of HN?" If the tool is web-based, it better damn-well be able to handle that level of traffic. Since DevShare falls into the "web-based" category and I don't want to pay for a bunch of servers, the solution is to go static and cache as much data as possible on the client-side.
Seeing as how most of DevShare's services are going to require some use of GitHub's API anyway, what makes more sense than hosting the front-end for free on GitHub Pages?
The front-end framework itself is still being worked out, but it will likely be built on Backbone.js.
I'm hoping that there will eventually be other "front ends" for the project, but this will likely remain the primary one.
Dev-ops
We're using Flowdock and a Hubot instance (named Ideabot) to automate tasks common to our organization in a visible and fun way. For example, this is how we do on-boarding: ideabot onboard <github_user> <email>
For continuous deployment, we have a Strider instance that re-deploys DevShare whenever there's a push to master that passes all of the Mocha unit tests.
That's all?
Well, that's not everything, but that's all the big stuff. It's been a fun few months designing the infrastructure of Devshare, and I'm proud of what we've accomplished so far.
There's still a lot left to do, though. If you're interested in the things I described in this post, we are looking for more developers-- just send me a message on Twitter.