Making CloudBees CodeShip Snappier with Vue

Over the last six months or so, CodeShip’s front-end team has been investing heavily in performance improvements by migrating more and more of our front-end components to Vue.js, and by improving how those components interact with our back-end.

We’ve deliberately taken an incremental approach with this work. Rather than one single big project, we’ve been incorporating it into all of our work - and all of our in-between work for over half a year now -- and it’s paying huge dividends.

We just finished up one of our favorite things to do - a self-directed sprint of work where our engineers take on any small tasks they’re passionate about. We wrote a bit about that recently if you’re interested in learning more.

One of our front-end engineers spent her time during that sprint expanding our Vue coverage to our teams page, and we wanted to use that as an opportunity to talk about this work in more detail.

What is Vue?

If you’re not familiar with Vue.js, it’s a Javascript framework for more simply building fast and powerful front-ends. Vue is data-driven, designed around objects and scales easily. For more information on Vue.js itself, you can read one of our engineering lead’s blog posts on the topic or watch him give a talk about it earlier this year.

Incremental approach

As Roman says in his blog post, we selected Vue because of its performance, how easy it is to introduce into exiting projects and because of the accessibility of the code itself.

With the decision made, we set out to begin implementation. So far, that has meant more than 30 pull requests with Vue updates over six months, as part of at least five different feature sprints.

And that work continues. What we’ve learned by taking it step-by-step is now being fed directly into new projects as we rewrite things like log handling and interactions between our build systems and our front-end application.

Performance gains

As the work continued, we’ve seen huge dividends, and most likely you have as well too. For example, our recent changes to our team pages cut the page load time down by 60% -- and that’s one of the smaller components we’ve refactored!

Webpack beats asset pipeline

When we started using Vue, we still leveraged the Rails Asset pipeline which is basically the Rails-native way of handling different asset files like javascript, css or images. Due to the flexibility of Vue, we could still leverage what this brought to the table but with a much improved quality of life via Webpack. Eventually, Rails itself officially adopted Webpack through the “webpacker” gem and we started moving our code over to leverage the improved integration.

This again brought a lot of benefits to our application. We could now leverage a better build process that is perfectly fitted for the javascript ecosystem, and along the road we finally had the opportunity to leverage some of what webpack provides: Common chunks splitting, treeshaking, environment based build files and more.

We ended up creating one special pack per application page and the benefits have been clear on both the user-facing and internal sides.

Pages driven by Vue apps

At CodeShip we decided to not move down the Single Page Application route that many modern javascript libraries, including Vue, suggest. Instead we leverage what a Rails-driven application brings to the table: server-side routing and rendering, including user session, csrf protection and more. A Vue app, in our case, is the content of just one page - such as the builds overview page. This means that we can have workstreams underway on multiple pages of our application simultaneously without the fear of interfering with each others work.

We can also leverage feature flagging on the server-side and load a completely different user experience for users without having code bleeding over inside existing experiences. This type of isolation makes ongoing migration to new code paths, like the one we’re discussing here, much easier to roll-out and clean-up.

Now we are able to prototype new apps in isolation at a very fast pace while still following CI best practices. We are sure we will not break the user experience for those who are not running the new application code and will keep an eye on things as we expand the roll-out.

Conclusion and ongoing work

Even though this is only a small summary of the work we’ve done, we hope it’s helped to make more clear the investments we’re making to deliver a better CloudBees CodeShip product - and inform you of what we learn as we do so!

We’re big believers in the idea of “continuous” around here (always keep shipping!), so we’ll keep you updated as we continue to learn from this ongoing, iterative project. It doesn’t have a completion date, as improving performance and making our code smarter and more accessible is a permanent goal of ours.

If you have any questions, don’t hesitate to reach out and ask.

Additional resources

• Read more about using Vue.js as a front-end to Rails

• Learn how to build a notes manager with Vue.js

• Find out why continuous integration is beneficial in the cloud