What’s your stack?

Might as well kick off our first post with a brief history of our tech stack, and how we got where we are now.

In the beginning, there was a content site started by the cofounders. It was built by a full service provider on Drupal, because sometimes you just need a CMS platform and there are mature tools to get it done.

And then at some point our CTO, Warren Habib, joined, and the first consumer product got built as a Ruby on Rails app. (First commit: 7/11/2013).

Then there was an interlude where there was a Node.js front end, with some cutting edge css and Gulp pipeline stuff going on; with a Scala micro-service backend. Yeah, bro, we were functional before it was cool. The plan at the time was to slowly move the heavy lifting over to Scala (things like security and encryption, because Java is way better at encryption, bruh), and keep Rails as a pretty little web wrapper to the outside world.

But… there were some big missteps. Basically the Rails style conventions dominated the Postgres database, and the chosen medium of communication between Rails and Scala was the database. And Scala at that time, didn’t really have a mature, lightweight ORM (there were some very powerful heavy lifters, but it was super overkill for our needs), so we ended up reproducing a good amount of what Activerecord does in Scala. And that was crazy brittle, and you had to make changes twice, and that was not sustainable. So we had to dump our cool boyfriend and admit that our parents were right.

So we kept all of the backend stuff in Rails. We also started to realize that our challenges were more in the user experience and product side of things, and we could get by on plain-jane CRUD and ORM style stuff for a long, long time to come (we’re still there, and we’re still doing just fine… kinda, but that’s for another post!).

Shortly after I joined we realized that the Rails front end code was unsustainable. It was your standard mess of jQuery sprinkles. So I tried to build something in backbone. We entertained that we had our own framework called Backwax (it was renamed to fluxxed_up and now lives on as a React/Flux pattern toolkit, if you search the git logs you can see what we did to ourselves) — Embarrassing admission that little mini Backbone app still lives on in our app, though its days are limited.

In the end we evaluated many of the leading front end js frameworks and landed on React.JS + Flux. The major why is probably enough for its own post — but in short we wanted something of ‘medium opinion.’ Something more reliable and straightforward than backbone; but not so proscriptive about workflow (for example, Ember, which was personally my first front end framework love). Along the way we made a test framework built on top of Mocha + Chai, and basically have a front end browser stack built in Webpack, with React.js, Flux, react-router, and a whole bunch of es6 plugins with babel.