My first foray into the programming world began in summer 2012 when I opened a chunky book on the basics of PHP. There, I picked up a whole host of otherworldly concepts that I simply could not apply to reality. Nevertheless, as I became increasingly familiar with what was previously on-screen gibberish, I began fitting the pieces together. During this process, I came across a tremendous amount of “best-practices”, “do’s and don’ts” and “how to avoid being that programmer”. After a while, you pick up a bunch of habits, some great, and some meh. This tendency of “sticking with what you know” is what I like to call The Great Compromise of Being an Effective Programmer. If you went down the rabbit-hole of trying to be the best programmer in your field, you may never come out. You will certainly never complete a project (if development projects can ever really be completed).
Then, we throw development frameworks and bootstrapping libraries into the mix. Good luck convincing other developers that your stack is better than theirs. Therefore, what do we do when have to pick between major web-frameworks such as Angular.js and Ember.js, a whole plethora of database structures and hosting-platforms? Pick the one that takes you the least freaking time to learn, and just get on with it! Because from my experience, which is obviously completely un-biased and totally objective, you’re going to come across moments of complete despair, wondering how much greener the grass is on the other framework. Chances are, developers from those other frameworks are probably eyeing up your lawn just as much.
So this is the part where I tell you things aren’t so bad.
Moving on… here are some specifics on our stack and our reasoning behind each one.
Database management: Parse
Parse is a back-end-as-a-service (BaaS) and perhaps one of the largest in the relatively new industry. We toyed around with their API on smaller projects back in its early days, and whilst the technology impressed us, the pricing did not. Fortunately, before we started-up Synap, Parse was bought out by, would you believe, Facebook. Certainly a strange purchase by the social-media giant, given that Parse is solely a B2B for developers.
– Off-topic digression – An assumption by my Co-Founder, James Gupta, is that Facebook wants to keep an eye on up-and-coming companies, sweeping in to purchase them in their early-stages before they become too expensive *cough* Snapchat *cough*.
So post-sale, Parse is now incredibly generous in their free-tier allowances. We have no limit to our API calls per month. There’s no limit to how many classes (tables) or attributes (columns) we can have in our schema, so long as we don’t exceed 20GB of data. They have a file storage allowance built into the service, also capped at 20GB, more on this later. Finally, mobile push-notifications for up to 1 million unique users, with no limits on how often we send out pushes. It was definitely a worthy platform for a budget-strapped startup. Having said that, once you reach the upper-limits of the free-tier, the pricing soon catches up on you. The first paid-tier begins at $100/m and doesn’t exactly add much to your allowance. Put it this way, once we start paying $100/m, we’ll soon be paying $800-1k/m.
What we like about Parse
It takes a matter of hours to have your database scheme set up, the API and docs are ready for you – there’s literally no hassle. Comparing that to my old PHP/MySQL stack, let me tell you, I tore out far fewer of my hair with Parse.
Authentication, both for secure-password storage and social-integration is taken care of. They also include a number of predefined hooks such as email verification for new signups and a password reset email/link.
What we would like Parse to improve on
Regarding their Cloud Code, Parse is quite strict on how much execution time we are allowed. Now, I understand they have to keep their servers efficient and by enforcing us on a time-limit, we have to be extra careful with the quality of our code. But, it introduces a terrible uncertainty with tasks that are crucial for the inner-workings of our product. I think a better way to handle this would be to warn projects that are running over their execution time, rather than to cut off potentially irreversible tasks.
Parse also provide access-control over individual objects as well as whole classes. This is great, and would certainly belong in the previous segment of this blog, but for the following problem. Say we have a User class. Say we need to store sensitive information on that class, such as an Email and Telephone number. Now, if we make the object private, it becomes difficult to fetch the user. We have to create a custom Cloud Code function that fetches the user using a master key, then, delete all properties that are sensitive – returning the stripped down object. This is a common work around which should really be built into Parse. Ideally, I’d like to set all User objects are publicly accessible, and be able to set individual properties as “only visible with master key or for certain roles”.
Finally, I think their console logs are a massive pain in the .
Front-end Framework: Ember.js
There is a risk that I will write a thesis on my views about Ember. So I’ll focus only on how Ember works with our BaaS, Parse.
The Ember community is fantastic and incredibly fast-paced. Ember 2.0 came out a week ago (mid-august 2015), and we are about 2 to 3 major builds behind. This is where my early rant about not being able to keep up with the latest and greatest stacks comes in. Ember ships with its own REST API management library, ember-data, and to be honest, it’s pretty sophisticated. Whilst it allows you to customise the REST adapter, it can be quite a steep learning curve, especially if you’re new to programming, or new to model-view-controller (MVC) frameworks, or new to Ember, or a sane human being.
For us, given that our REST API is structured by Parse, we needed an Ember-Parse library. Luckily, we found one, ember-parse-adapter. I’ve been working with this library for the best part of a year now and unfortunately, it has only been updated once during that whole time. As Parse updates its docs and as Ember updates ember-data, I am left with quite a mess. At this stage, I have had to extensively modify the library to match our needs. It’s not ideal, but it does the job. The down-side is however, we cannot upgrade to Ember 2.0 until the ember-parse-adapter is fully compatible with the new ember-data package.
What we like about Ember
Highly-opinionated and structured framework. Robust handling of routes and state transitions. Lots of plugins and 3rd party libraries.
What we would like Ember to improve on
Ember guide docs have been hit and miss, especially whilst new builds are released. It’s something they’ve promised to work on with this new major release. But we’ll have to wait and see.
Server hosting: AWS Elastic Beanstalk, S3 and Redis
We picked AWS to handle our Node.js server. All it does is receives a call along the lines of ‘https://synap.ac/link/to/page’, ignores the ‘/link/to/page’ and simply sends our index.html which is stored on the Node server. Now, every time we update our project on Ember, we upload all our assets on an S3 bucket, links to those assets are referenced in our newly generated index.html and finally, the index.html is uploaded to Redis. Our Node server intermittently checks Redis for updates, and caches the latest index.html, spitting it back out to any url request. The actual page routing is done on the client, by Ember. Magic really. Currently, this setup costs us next to nothing and can handle an impressive amount of stress. Our server is not really having to figure much out, so it takes a lot of concurrent calls to cause it any trouble.
What we like about AWS Elastic Beanstalk, S3 and Redis
Cheap, flexible and scalable.
What we do not like about these three
This setup is not one that intuitive to inexperienced programmers. We had a lot of sleepless nights trying to get our head round this. If you’re in a similar situation, tweet to me @OmairVaiyani and I’ll talk you through it.
Services we like to use as a development team:
– Codeship: streamlines building, testing and deployment
– Trello: light touch task management
– Slack: light touch team communication
– Intercom: user support and engagement, can get pricy but cheaper than hiring a support team.
Our technical stack is not the most sophisticated, rigorously efficient and unbreakably robust architecture that one could build. But, it’s better than what most tech startups can afford to build on their own. Our use of Software as a Service (SaaS) platforms has given us a massive leg up, and allowed us to focus on what we do best.