TinyWins has been a pretty big learning experience for me. End to end it is built in JavaScript. I chose JavaScript because it is the language I’m most comfortable with, which also means I have the most fun building with.
At a quick glance this is the break down:
Backend
- Hapi.js - was used to build the API end points
- MongoDB - for its database
- DigitialOcean - where the API is hosted
- LetsEncrypt - generates the SSL for the backend server
Frontend
- Ember.js - consumes the backend API and provides the view layer for the end-user
- Jekyll - is used to generate the marketing pages found at tinywins.net. It is also used to generate the blog and journal
- Amazon S3/CloudFront - both the built versions of the Ember app and Jekyll project are hosted on Amazon’s S3. It is then served through Amazon’s CDN service, CloudFront so that it is delivered as quickly as possible
Other APIs
- Stripe - is used for processing payments
- Amazon SES - is used for transactional emails
Why seperate front from back?
Previous to building TinyWins, its predecessor, was built in Ruby on Rails. It was actually my first forray into Ruby on Rails. Although I enjoyed learning a great deal about Ruby on Rails, personally it just slowed me down a great bit because I hadn’t gained enough knowledge of the framework or of Ruby.
With TinyWins, I felt that having a single framework handle both the front and backend was limiting to me. I enjoy working with Ember.js and although I could’ve eventually hooked up Ember.js to a Ruby on Rails backend, I decided against it. So I took a API-first approach and built the backend using Hapi.js.
This way I had an API that could simply serve up data but could be hooked into various front side clients. The Ember.js app is fully responsive and if you’re on iOS you can save the site to your home screen and you’ll have a nice iOS compatible icon as well as the app launching without the UI elements of Safari. This makes the app feel very native.
But the API-first approach was also chosen so that if I decide to build native applications for either iOS or Android, I could do so and the application doesn’t have to be built from the ground up to accomodate it.
Another benefit from separating the front and back layers is that the built Ember.js assets are just HTML, CSS and JavaScript, so I can push it up to a CDN for fast delivery.
Would I swap out anything?
I’m still tweaking and learning about the stack I have chosen. I’m doing my best to tweak each part for optimization which has been fun to learn about.
I haven’t done a ton of research into it, but I think if I was to swap out a piece of my stack, it probably would be the database. I chose MongoDB, because it is the database I have the most experience with. Upon reading several articles, I’m learning that MongoDB isn’t the most secure and could have some degradations.
I’m a pretty paranoid person. For my family’s collection of photos, I’ve got a couple of local backups and it is also backed up to S3/Glacier. Seeing that I’m providing a service where people are relying on the service to help them stay productive, I want to make sure I don’t lose their data.
As such, I’ve got a rotation of backups from the database to S3. Which helps alleviate some paranoia of data loss, but I’d like to make sure it doesn’t happen anytime soon. For this reason, if I was to swap out a piece, I’d probably swap out MongoDB for a traditional relational database like PostgreSQL.
Why did you choose each piece?
A few years ago, at a previous job, I was tasked with learning and implementing the front-end of a product with Angular. At the time, Angular was still version 1 and it was on the dawn of rolling over to version 2. I’m not entirely sure if the story changed at all when the transition from 1 to 2 where the entire community was a heap of mess because Angular 2 wasn’t backwards compatible with Angular 1.
This made me wary of it because although Angular was the hot framework, I also thought that the fact that it wasn’t backwards compatible in the major version upgrade, it would be a problem down the future.
I researched for a very long time until I came across Ember.js. At the time, Ember.js was close to verison 1. Although it was pre-version 1, I read countless stories about folks running applications in production on pre-version 1 code. Also the core team that was managing the application wanted to make sure that changes to the framework would always be backwards compatible.
I saw this as a feature. As someone choosing a piece of tech to be part of an applications stack, I didn’t have to worry about updating the framework thus protecting my users from the latest vulnerabilities or enjoying the latest and greatest feature.
I’ve now built several web applications with Ember.js over a span of 3 years and have enjoyed it very much. It isn’t the hottest framework like React, but it is very mature and I love the fact that like Rails, it is convention over configuration. This allows me to quickly get to developing instead of worrying about the various pieces to get the framework working. Not to mention Ember.js’ documentation is top notch. It is one of the few projects whose documentation I have fell in love with. It is just written really well so you can gain the knowledge you need to build.
Although, I chose Ember.js because of its convention over configuration, which was heavily influenced by Ruby on Rails. For the backend I chose to go with something lean and simpler. At the time I started building the backend Rails had officially dropped version 5, which had an API-only mode. But the documentation was lacking so it was hard for me to wrap my head around using it.
Looking over the JavaScript options, I was left with either using Express, Koa, Hapi or more full stack frameworks like Meteor. I knew I wanted to use Ember.js and not React or Angular so I decided not to go with Meteor. I checked out Express, and although it was by far the most popular library to use for building APIs in JavaScript, the project looked like it was losing steam and making way for Koa. Although I’m sure Koa is a lot better, what’s not to say that the team wouldn’t abandon Koa as well somewhere down the line.
For this reason I found and decided to go with Hapi. Hapi was born out of Walmart Labs. It was battle-tested during black friday. The folks contributing to the project seemed to be in it for the long haul with an emphasis of modularity. So I decided to go with Hapi.
If you haven’t caught onto the pattern by now, I’m basically piecing together a tech stack that will stand the test of time. With JavaScript, there is a lot of noise and libraries come and go. The pieces of tech that I did choose, I hope they will help sustain TinyWins for a very long time.
I think this is why so many companies build with PHP and Ruby on Rails. Both pieces of tech have been around for a very long time and it enables the companies to focus on building and not worrying weather the support of a project will be dropped in the near future.
Questions?
I hope this has been insightful in the various tools I’m using to build TinyWins. If you have any questions regarding any piece of the tech stack listed above, feel free to reach out and ask.