I’m @1000ch, and I’m writing about the new Mercari Web. The release of this big project was achieved by the great contribution of many people. I’m going to write about the project from its inception to the present day, documenting the entire project as a lead.
Legacy Software in Mercari
It is often said that software is a living thing, and how to deal with outdated software is an issue that every development organization has or will encounter at some point. In order for a large number of people to use the software, it is necessary to develop and maintain a large group of software. However, it is impossible to build a perfect architecture that anticipates everything from the beginning, and it is the responsibility of engineering to make the software grow to withstand the growth of the business.
Mercari, which was launched in 2013, is no exception, and there are many legacy areas that have been held back by the rapid growth of the product. For example, one of the improvements we have been working on is the Backend microservices. Mercari Web was one of the many technical depts.
Mercari Business and Web as a platform
One of the reasons for the focus on native applications in the case of mobile devices is the performance of the device, but when targeting desktop devices, the focus will be on the Web, where the browser provides sufficient performance.
The decision was made to relaunch the web version of Mercari in order to leverage the various business potentials using the web, such as differentiating the experience from the mobile device experience in the long term, and taking advantage of the affinity with the outside of Mercari, such as the influx of traffic regardless of whether it is mobile or desktop.
Relaunch of the project to restart Mercari Web
Efforts to revamp the legacy Web were already underway. However, it was difficult to speed up the process and the project was taking a long time because of the repetition of partial replacements while keeping compatibility with the existing Web and developing functions at the same time.
So, we asked ourselves what we wanted to achieve with the future of the Mercari Web.
- Software should be robust enough to withstand mid-long term product growth by discarding technical depts speedy
- Application should be accessible and internationalized, and provide the same functionality as the iOS and Android versions, whether desktop or mobile.
- Orgnization should be ready to make a continuous commitment to the web, not only before release, but also after release.
With this common understanding in mind, we decided to re-partition the legacy web revamp that was ongoing and restart the project. Of course, at the time of this release, not all of the functional equivalence and technical debt return have been achieved, but many of them have been, and the resolution of the remaining issues is finally in sight.
In addition, the new release does not include any new features, but rather focuses on replacing the software without significantly changing the customer experience.
Application Architecture
The engineering team at Mercari had enough knowledge and experience with React and TypeScript, so we chose Gatsby as a build system to adopt SSG that scales independently from Node.js runtime (although we were later swayed by Next.js’ Incremental Static Regeneration).
The APIs necessary to implement the functions are already provided, and for the parts that have already been migrated to microservices, we used proto files to output TypeScript type definitions.
For the search engine crawler bots, we adopt GoogleChrome/rendertron to return the complete HTML. As you can see, there is nothing special about the design of the overall architecture of the application.
Trunk-based Development and Test
We use trunk-based development, and accordingly, the git operation creates new branches from the trunk main branch and merges them into the main branch as soon as development is complete.
As part of continuous integration, various tests are included in the build pipeline. Unit tests and E2E tests are a prerequisite for all development, and especially for E2E tests, the engineers responsible for feature development. Engineers are responsible for defining and implementing the test cases with the review and cooperation of the QA team, and branches that are not well tested cannot be merged into the main branch. This ensures that the main branch is always available. This ensures that the main branch is always in a release state.
Internationalization (i18n)
In order for more customers to use our product in the future, we have been developing it on the premise that it will have a foundation for internationalization. As the first step, we have been implementing support for Japanese and English. However, in order to achieve this, we need to fully consider not only the web application part, but also the implementation of the backend side, and how to support communication between customers on the item detail screen and item transaction screen. For this reason, only Japanese language support is available at the moment.
Internationalization and accessibility, which I will explain next, are also recognized as important factors for Mercari to become a diverse product.
Design System and Accessibility (a11y)
In parallel with this project, an update of the design system has been implemented. We reviewed the design system that we had been working on up to that point, and worked to improve it with two goals in mind: improving accessibility and providing functionality that does not depend on a specific UI library. Since the design system is designed to be the basis for building UIs, so if accessibility is guaranteed at the design system layer, the accessibility of the built UI should also be less likely to cause problems at the implementation level.
The basic policy of the design system is that it should not be dependent on any particular platform or library, and based on this, we made the decision to use Web Components as the implementation technology for the design system components. For example, components can be implemented in React, but they cannot be used in projects or plain HTML pages that are built with Vue.js, and if they are implemented in other libraries such as Vue.js, maintenance costs will be multiplied. Web Components, which is composed of Web standard technologies, is good in terms of ensuring portability as a component, but it is still immature in terms of compatibility with the use cases required in web development, and we have encountered various difficulties.
I am sure that the test operation and design system will be explained in another article.
Project Progress and Organization Structure
I think it was not so much the technical aspects that needed to be worked out, but rather the organizational aspects, such as the promotion of the project and the organization of the team. Executing this project and releasing a new version of Mercari Web is not the only goal, but we need to install a system in the organization that can sustain the commitment.
The development organization at Mercari has adopted a Camp structure. Each camp has a mission, such as "Camp-X is responsible for the customer’s buying experience, from searching for a product to making a purchase" (This is just an example and not the actual mission. Camps with different objectives come together to improve the functionality provided by Mercari).
Ideally, each Camp should create functions according to the mission that they are in charge of, but since it is difficult to put this into practice from the early stages of a project, a Camp with the objective of "rebuilding the Mercari Web from scratch" was formed as a task force.
However, in the early stages of the project, we started with a small team of two software engineers (excluding myself), one product manager, and one designer. From here, our recruiting efforts with the help of the HR team paid off and many software engineers joined the team, and the existing Camp gradually shifted to a system that commits to the new Mercari Web. It took us about a year and a half. I would like to thank everyone who has contributed to this project.
Mercari Web from now on
In the future, it will be important to focus on the organization structure by dividing the roles into a team that maintains the basic parts of the application and a team that expands and improves functions based on the mission of each Camp, to develop the Mercari Web in the mid-long term. I believe that by providing superior functionality on the web as well as on iOS and Android, we will be able to grow as an even more inclusive platform.
"I want to use Merpay on the Web!" and "What’s going to happen to Mercoin?" and "What about Mercari Shops for the Web?" There are some things I can write about here and some things I can’t, so please forgive me. If there is one thing I can write about, it is that we are looking for various possibilities for the web and we are short of engineers, so please refer to the job description and apply.
