Everything that has a beginning has an end, or ‘the short version’
Bidvine was founded in 2014 on the idea of connecting customers with local service professionals in a way that provides successful outcomes for all involved. A simple enough idea, but would it work? The answer was yes, and better than we thought it would. A prototype website was flash-built in late 2014, and by early 2015, it was clear that this prototype website was not going to last.
Bidvine is a marketplace, and needs to have efficient user acquisition on both sides on the marketplace, but also provide an efficient communications layer that underpins the core interaction, and also that forms the core utility of the platform.
Being a website built on acquiring users, we are by necessity built on acquiring data. We resolved on Ruby on Rails for our prototype website and it could not cope with the data. We also needed to build scalable, intuitive user interfaces as part of our role as this communication layer, and our launch day Ruby on Rails site had no frontend at all.
Fortunately, we were a(n) (even) young(-er) startup then and had the flexibility and mobility to shape our future: as a business, and as developers.
After using this Ruby on Rails site as our MVP through our Techstars London Demo Day launch in February 2015, we knew that we needed to build out a proper front end, and also extract the API into a serviceable and scalable backend.
We considered Angular, Ember, and React for the frontend, and, for the most part, we didn’t consider anything but Node.js for the API.
The process of rewriting our website was not a simple undertaking. We submit this document as proof that it can be done, as a guide to those who would do the same, and as a thank you letter to the Ember community.
We faced a dilemma: refactor our existing site built with Rails, or rewrite and improve our site using a different framework? The more pressing question, as its answer would inform the answer to the first question, was what framework should we be rewriting to?
Based on our collective experience as web developers, we surveyed the landscape of the web and tried to identify toward where web development was trending to make our decision. Immediately, several choices were obvious:
- Stay with Ruby on Rails because it seemed to work for many others,
- Use ASP.NET MVC, or
While Angular was committing to an Angular 2 upgrade that would require anyone using Angular 1 to largely rewrite their whole website, Ember was committing to a smooth upgrade path with a steady stream of deprecations, and a clear path forward. Angular was, thus, out of consideration if we were to have to rewrite our application to Angular 2 just after we finished rewriting it to Angular 1. We were left with two choices: Ember, or React. We ultimately chose Ember because Ember is a complete framework and React is not. When we made the decision, React had a relatively small community behind it compared to what Ember had. The same decision would be a much more difficult one now, given React’s recent growth in popularity, but this was early-to-mid 2015, and we had our way forward.
Now that we knew our destination was a full Ember website, we had to figure out how to get there. To test this decision, we chose to try out Ember first on our internal admin users. The initial release was to be simple: basic listings and details views for our two primary data types. The implementation of this simple release was decidedly less so.
Overall, this might not seem too bad, but we went from one domain (www.bidvine.com) to two subdomains (www, and an admin domain). Keep that number in mind, because it will get worse throughout the process. And, as every developer knows, when you overcomplicate your development environment, things inevitably go wrong. With three things now required to run our site (and more to come), a lot of time got wasted dealing with local environment issues. Not to mention, we had to expose an API for Ember at this point, which meant we had duplicated logic within our Rails code that we had to maintain for two different applications.
All said and done, the alpha test went well for all involved. The admins were happy to have a fancy, responsive new website to use that didn’t crash all the time, and we had a proof-of-concept that we could build our site using Ember.
The beta (goes wrong)
Confident in our understanding of Ember, we endeavoured to move a piece of user functionality to Ember next. Our user onboarding procedure on the supply side of the marketplace needed an overhaul and we wanted to add public user profiles, so we started there. Again, the plan was simple, but it ballooned the complexity of our setup in a way that we didn’t expect. Because our admin Ember application was using a full theme, and Ember didn’t, and doesn’t yet, have an option to conditionally include resources, we created another Ember application.
With another Ember application came a third subdomain (pro.bidvine.com, which no longer exists). We also had to now start redirecting from one subdomain to another within all the applications themselves, which introduced complexities in maintaining proper user flows throughout the site. The added complexity of these new applications also caused our staging environment to fall into irrelevance as we did not keep it up to date with the new changes.
Needless to say, we messed up. Big time. The initial release did not go well and we got called on it. Without a proper staging environment, we had a plethora of issues with session cookies being lost across subdomains, mixing HTTP and HTTPS, and redirects not working as we’d intended. The bugs were trivial and easily fixed, but we learned a valuable lesson about quality assurance.
Apart from the initial troubles of this release, we had further proven that Ember was the way to go. However, as a startup, we couldn’t justify writing off the next 3 months to rewrite the whole platform. Yes, we needed to continue to move functionality to Ember, but we also needed to overhaul it as we did. Our platform itself was a proof-of-concept and we needed to become a fully actualized platform for connecting customers with local service professionals.
The Big Boss!
Rather than port all the existing functionality over at once, we chose to move the user-centric functionality, which meant the admin pages and things tied to authentication stayed on Rails. As a result, most of our website would now exist on a secondary subdomain, and the primary subdomain would have to frequently redirect out of itself. While not an ideal solution, we weren’t yet concerned with search engine optimisation (SEO), and we couldn’t justify porting it all at once.
Remember that count of subdomains? We were at two, and then three between two Ember applications and the Rails application. Well, we decided to throw a fourth into the mix at this point too: a Node.js/Express.js API. It might seem excessive, but we were planning for the future and our Rails API was minimal so it was a now-or-never decision. The complexity of the new API was minimal as well, but we did have to pipe certain requests made to the new API through to the old one for authentication purposes. Again, it sounds trivial, but when hosting with a DNS service that tries to protect you, and it blocks piped requests within a domain, unexpected complexities can foil a release.
We dubbed this release our “Big Boss” release because it was going to be a great accomplishment for us in terms of moving away from our MVP of user functionality and be the first release that would include full on-site communication tools between users. We added a number of new features, greatly improved a number of existing features, and generally made the user experience look and feel like a proper website.
The complexity of this release can’t be overstated. Mixing two APIs and three front-ends together was a nightmare from a dev-ops perspective, and there were hiccups during the release that caused a rollback, a one day delay, and a lot of lost sleep.
We triumphed, though, and the now we had an exciting new way for our users to interact. User reception of the changes made was overwhelmingly positive, and the website performance improved significantly. At this point, the only remaining step was to go full Ember + Node and cut the cord with Rails.
Going off the rails on a crazy train
With experience comes wisdom, and we knew what we were doing now. We moved the remaining admin and authentication functionality from Rails to Ember + Node without anything of particular importance to note. Decisions were made, such as what type of authentication to use and how to implement user sessions, but from a development perspective, this final length of the journey went relatively smoothly compared to the previous hills and valleys.
Our initial angst about splitting our site into two Ember applications proved to be unjustified. In retrospect, having these two platforms exist separately is a huge benefit because the two applications perform very different functions and use the data models in very different ways. We were, finally, a stable platform once again. Although this might seem like the end of the journey, other considerations persisted, and continue to persist, which must always be accounted for.
Ember knows best
Upgrading from Ember 1 to Ember 2 (on two Ember applications) was a huge task! Every little trick, every private API, every loophole you found to shortcut the way Ember really wanted you to code, gets deprecated eventually by the Ember team. Every minor version upgrade of Ember introduces some new deprecations or bugs to our applications that must be resolved. This wasn’t just a one-time deal either: Ember is always changing to make sure it stays relevant. Such is the appeal of Ember, and also the bane of an Ember developer’s existence.
How (not) to SEO
Looking back over a year and a half of using Ember, we are struck by how helpful the Ember community has been. The emberjs.com guides, all the Ember add-ons, all the StackOverflow questions and answers, and all the Ember GitHub boards are invaluable resources to an Ember developer. If we had to make the same decision again about what framework to build our site on, we would still choose Ember.
We continue to add new features, enhance existing features, and generally improve the overall stability and accessibility of our website. We contribute back to the Ember community where we can and we thank the wonderful Ember Core Team and community for being awesome at what they do. What’s next? We’ll be sure to keep up to date on Ember so that we can continue to release exciting new features to the users of Bidvine!