Learnings from our first SPA

Recently I shipped our first single-page application (SPA) and I want to share my thoughts and experiences with the development process and how different this experience was compared to what I’m used to.

Give it a try...

At Inspire, most of our projects are done with Ruby on Rails. While the development speed it brings is extremely convenient, it is hard to efficiently split tasks between frontend and backend developers as the MVC approach of Rails tied them together closely. Hence our decision to give the single page application (SPA) a try.

Developer Steven working
Developer Steven

Seperation of concerns

With the approval of my co-workers, I decided to create our latest project with an SPA for the frontend, and an API exposing a GraphQL endpoint on the backend. This approach brings immediate benefits: each developer or team can focus on his part while respecting a common contract in the middle. The time when a frontend feature cannot be started because the backend equivalent is not ready yet is over.

For the frontend I limited my choice to the two main usual suspects: React and Vue.js. As I already have quite some experience and projects with React (Native), I went for Vue.js to broader my skillset and see if I could learn something new from it.


As the routing is made on the client side, the application doesn’t rely on any controller to deliver a new page. You can then build your frontend from A to Z without any interaction with the backend. Mocks can be quickly created if something is missing. On the backend part, the presence of GraphQL makes things extremely flexible: As a classic REST API will always deliver the same set of data, you’ll to create and call a new endpoint if your needs are a bit different.

With GraphQL, the frontend application is responsible for composing the requests, but also what it wants in returns. It means there is no need to change the API, provided the requested resources exist and can be served through GraphQL

"On the backend part, the presence of GraphGL makes things extremely flexible."

Faster Iterations

If I would compare my previous experience with Rails to Vue.js, I would say I definitely felt more productive with Vue.js after a week learning it.

The main reasons for that are the great devtools associated to the framework, allowing you to inspect, alter and debug the entire application, seeing how your components react to new props and what triggers which changes in your data stores. Time rewinding is also extremely useful when you want to reproduce an issue step by step, and discover which mutation introduces the unexpected behaviour. (plug: vue-devtools v5) just landed and is shipped with even more great tools, check it here.

The other reason is the hot reloading feature. Every single change in the code will be reflected in the browser without having to reload the page. It is especially appreciated when you need to work on the style of your application.

Solution to all the problems?

So are SPAs the solution to all our problem? Probably not, and let’s not forget there is no solution covering all our needs. As developers, it is our responsibility towards our clients and coworkers to pick the best tool for each project.

That said, I would definitely like seeing more projects done with a Single Page Application, backed by React or Vuejs. And why not including these frameworks in our Rails applications to handle complex pieces of UI.

Vuejs was a really good bet at the end. The opinionated yet flexible structure it provides makes development really easy.