-3

We're currently developing a product which will have a Web version and a Mobile version. At the moment, the plan is to have identical features on both of these.

From a tech perspective, there is an opportunity to reuse a lot of the business logic code because both products are developed using a React framework which has versions for Web and Mobile (i.e. React Native).

Doing this would enable a single developer to specialize in certain features across both platforms and avoid repeating the same logic between them. Our engineering team recommends this approach and they would like to have a monorepo.

However, it is more difficult to manage from a product perspective as Mobile & Web products become coupled, i.e. it is unpractical to separate the feature sets if that becomes a requirement and any bugs introduced in the business logic layer would spill over to both platforms.

Are there any best practices here and pitfalls to avoid?

Thanks.

1 Answer 1

2

The decision to use a single repository for both the Mobile and Web versions or to use multiple repositories should depend heavily on the release cadence of the two versions of the product.

If it is the expectation that new versions of both the Web and the Mobile version will be released (closely) together and in the off chance that you have a release with only changes for Mobile, that a new Web release is also made (or vice versa), then a monorepo has no real drawbacks and only advantages.

If you have different release cycles for Mobile and Web, then I would recommend to use 3 repositories: 1 with the business logic that will be shared, 1 with the Mobile UI and 1 with the Web UI.

The big advantage of a single repository with the business logic is that this only has to be implemented once and any problems/changes also only have to be fixed once.

Unless you have two teams (one for Web, one for Mobile) that do not communicate with each other and don't have access to each other's code, the most likely scenario that will happen if you insist on two repositories with each their own copy of the business logic, is that team 1 will just copy the relevant business logic from team 2, including all the bugs they made (and possibly introducing some extra bugs in the process). That way, you still have the same bug on both platforms, but now it needs to be solved twice and you also need more communication between the teams to inform each other about bugs that were solved in copied code.

With properly shared business logic, you get a faster development of your features (because the, typically complicated, business logic has to be done only once), you get a better architecture (because the business logic has to be properly separated from the UI logic to support multiple platforms) and you can still differentiate the products by varying which use cases are accessible in each version.

1
  • Thank you for a detailed and thoughtful response.
    – pvukovic
    Dec 22, 2021 at 21:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.