Our platform architecture at Mews initially consisted of a monolithic backend and several frontend applications. Over the years, however, the functionality we cover has grown significantly. Eventually, our backend became so large and interconnected that it became difficult to work with.
While starting with a monolithic backend was likely the right decision at the time, the increasing number of customers on our platform has led to growing demands for scalability. Our engineering team now believes it is necessary to split our backend into multiple independent services, each dedicated to different domains and independently scalable.
But how can we achieve this? The only possible way is to start gradually, migrating one domain to the new architecture at a time.
Rewriting GuestPortal
One day, the leadership of the Guest Experience tribe proposed a project to rewrite GuestPortal: our product for online check-in, checkout, upselling, and more.
A software system rewrite is a huge investment. When you decide to go this route, it’s essential to consider what else you can fix. This might include revising the product’s feature set, revamping the UI, creating a fresh design, and finally making it mobile-first!
Our project came with several additional requirements:
- Deadline in 6 months: Our goal was to present the redesigned product at the Unfold conference.
- Feature parity with the current GuestPortal version.
- Foster collaboration with other teams at Mews.
- Use the internal developer platform Atlas for the backend.
- Utilize the Mews Design System and improve mobile usability.
- Ensure seamless integration with the new Digital Key product.
Choosing the right approach
For a big assignment like this, you have three possible approaches:
- Improve your current codebase: Sometimes, it’s better to avoid radical changes and focus on improving your existing codebase. This is a safe option, but implementing significant changes can be challenging.
- Greenfield rewrite: In other cases, your current solution is so difficult to work with that starting from scratch becomes the better choice. While this is a risky option, it allows you to avoid dealing with the quirks of the legacy system. The downside is that you can’t present the new version of your product to customers until everything is complete.
- Rewrite your app piece by piece and continuously integrate: This approach gives you the best of both worlds. It acknowledges the need for a new system while allowing gradual implementation. You can get faster feedback and safely present finished parts of your work to customers along the way.
We chose option 2, the greenfield rewrite. Considering the strict deadline, we felt this approach would require the least total amount of work.
Building for mobile
The design of the new app was created entirely from scratch. During the first couple of months, we focused exclusively on the mobile version. This approach encouraged everyone on the project to prioritize making the product highly usable on mobile devices, which are now the primary choice for most guests.
Revamping the backend
For this project, we decided to create a new backend service outside the monolith using our internal developer platform, Atlas. Developed by our platform team, Atlas provided all the necessary infrastructure and a backend C# service template to enable microservice development.
This decision gave us a fresh start, allowing us to experiment with new technologies and approaches effortlessly. Having a separate service also made it easier to scale performance independently of the monolith.
Switching to GraphQL
Our previous REST APIs did not adequately support frontend needs. They were poorly structured; some screens required many requests to load data, while others returned more information than necessary. Additionally, the lack of computed data in the API forced us to implement a significant amount of business logic on the frontend, making it difficult to maintain.
To address these issues, we created a new GraphQL API. It provided the right data, making it easier to use on the frontend. We also shifted a significant amount of business logic from the frontend to the backend. With GraphQL, we benefited from code generation and an easy-to-explore API, which greatly improved the developer experience.
Would you be interested in helping us break down the monolith?
Check out our open positions!
Simplifying frontend architecture
The previous version of the frontend app had a complex architecture based on the Redux library. Any component in the component tree could read data from the global Redux store or trigger actions, and the app relied on sharing state across screens. This made the code difficult to understand and resulted in poor testability.
With GraphQL, we introduced a much simpler architecture. Each screen loaded its data independently in a single smart component, which then passed it down to a plain, logic-free view component and its children.
Storybook
This architectural change made it easy to test the UI of entire screens in Storybook. It allowed us to:
- Start frontend development before the backend was fully implemented.
- Test app states that are difficult to reproduce.
- Share work in progress with designers to gather early feedback.
In the early phases of the project, we even used Storybook to demo our progress.
Streamlining QA with the mini.Mews tool
During the development of the new GuestPortal, we needed to create a large number of reservations to test the new flow. Normally, this would be a tedious task. Fortunately, our QA team developed an internal tool that allows us to create a standard reservation with one click or a customized one with just a few more.
This tool proved invaluable not only for developers but also for PMs, designers, and demo purposes. It’s amazing how a large project can spark unexpected innovation.
Project outcomes
Delivering this ambitious project wasn’t easy, and unfortunately, we had to compromise in several areas:
- Deadline: Instead of releasing the product for general availability at the Unfold conference, we made a development announcement and quietly began onboarding beta customers.
- Scope: We adjusted our target to meet the needs of 90% of customers, rather than achieving full feature parity.
- Architecture: We didn’t fully leverage the potential of a microservice architecture.
- Long feedback loop: We received our first customer feedback after six months of development.
However, our list of achievements is still impressive:
- We introduced a fresh look and feel with a new design system theme and improved the user experience.
- We optimized the UI for mobile.
- We moved business logic from the backend to the frontend.
- We removed the Redux library from the frontend.
- We’re now using the Atlas platform in production.
- We became the first team at Mews to use GraphQL in production.
Key takeaways
While rewriting the GuestPortal involved tough decisions and compromises, it allowed us to significantly improve the user experience, scale our backend, and experiment with new technologies like GraphQL and microservices. The project wasn’t without its challenges, but the lessons learned and the progress made will be invaluable for future projects.
We gained valuable insights throughout, and I hope I’ve been able to share some of those with you. What’s your opinion? With this information, would you have done anything differently?
If you’re interested, you can watch the talk that inspired this article on our YouTube channel.
