A group of four engineers took two weeks to build the initial front-end application in Ember and React. This included boilerplate tools we needed such as authentication and assets, and some commonly accessed pages. Thereafter, we sent an email to all of our engineers to take a week implementing specific features within the Ember and React applications. It took a bit of coordination due to engineers being on separate teams but we managed to make it work by staggering it across 4 weeks. Below is the email that kicked it off:
Once everyone finished their implementations, we started sharing the feedback within the team and did a retrospective on this experiment. During the experiment we had two new frameworks that made it into the mix unexpectedly. Angular 2 and Vue were introduced as people had extra time and believed they can also help solve our problems. Needless to say, there were plenty of opinions in the form of 32 lengthy emails, 12 pages of notes and too many Slack messages to count. The decision on our front-end framework boiled down to these five considerations:
- The community around the frameworks and how active they were.
- Our feature development process at Doximity. We work in two week iterations and allocate resources often towards spiking new prototypes and split testing new ideas. This was easy for us in Ruby on Rails, and we didn't want to lose velocity in this regard.
- Ease of implementing features following good design practices without fighting the framework. Ruby on Rails, once again, made this easy.
- Coordinating work with our design team and leveraging our Vital CSS framework.
- Writing end-to-end tests, which we never found ideal within a Ruby on Rails application.
For the majority of these decisions, React and Vue met most of our needs. We are all big fans of Ruby on Rails, especially for the convention over configuration aspect of it. React often led us into bikeshedding discussions. But with Vue - it just worked. Therefore, we chose to move forward with Vue slowly.
The Vue Forward
So, how were we planning to migrate our front-end features to a Vue SPA? The plan was going to take the better part of a year but we wanted to approach this cautiously. There was no rush. Here’s how we did it:
- We knew we had a lot of front-end components that we needed to build or port over from Backbone. Therefore we catalogued the components we had and the ones we would need and began work on these. We weren't implementing any user facing features but simply building the backbone so engineers can focus on building features. We eventually open sourced the project called Genome.
- We identified all the required features we needed within the SPA to build our pages - from server side rendering, to deployment strategies, to state hydration and created stories to track them.
- Following this, we had two dedicated engineers working on the SPA implementation to ensure the required feature sets were brought into the mix.
- Meanwhile, we provided material for other engineers to brush up on ES6 and Vue through online courses and books.
That brings us to where we are now - implementing user facing features with a single MOFO team. Keeping the implementation to a single team will help us continue to polish the SPA while we get our feet wet with Vue.
We could have moved much faster if we wanted to, but there is value in carefully evaluating technologies as they pertain to our business and teams. In this case, we chose to move slower with purpose and not break things.