Over the last few years, in order to facilitate growth of our UI applications, we had to make a few architectural decisions like turning to monorepo approach, distributing private packages with npm or adjusting continuous integration setup. In this talk I'd like to share the pain points we've encountered throughout the way, as well as to present benefits of the approach we've worked out compared to more traditional alternatives.

1. React Apps at AirHelp
Lessons Learned

4. Business background
Icons: fontawesome.com

5. Business background
balance sheets
legal actions
transactions
court cases
jurisdictions
lawyers
Common domain
vs different use cases

8. Pain point no. 1

10. Pain point no. 2

11. Pain point no. 3
All legal applications are tied up with the latest version
of commons library.

12. Private npm packages
• $7 per account
• works out of the box
• remember about a token for CI

13. Pain point no. 4

15. Yarn Workspaces
Yarn Workspaces is the first step of what a package manager could do
for managing monorepos as they become a more common solution to
code sharing.

16. Pain point no. 5

18. Lerna
Lerna is a tool that optimises the workflow around managing multi-package
repositories with git and npm.

19. Rush
If you're looking to break up your giant application into smaller
pieces, and you already realised why it doesn't work to put each
package in a separate repo... then Rush is for you!

24. Custom commands

25. Pain point no. 6
A perfect monorepo setup?

26. Pain point no. 6
A perfect monorepo setup?
Almost! Too much hustle when releasing often.

27. Pain point no. 6
Almost! Too much hustle when releasing often.
A perfect monorepo setup?
Should we take a step back?

28. • Module resolution not well supported by IDEs
• Synchronous execution of monorepo-wide commands
• Missing utilities

29. Why all these efforts?

30. Why not repository per app/package?

31. Why not repository per app/package?
Coordinating multiple pull requests

32. Why not repository per app/package?
Coordinating multiple pull requests
Don’t test developers on their laziness

33. Why not a monolith?

34. Why not a monolith?
Coupling between backend and frontend

35. Photos: Laurentiu Garofeanu/Barcroft USA

36. Why not a monolith?
Coupling between backend and frontend
Added complexity

37. Why not a monolith?
Coupling between backend and frontend
Added complexity
e.g. webpacker, react-on-rails 👎👎👎

38. Why not a monolith?
Coupling between backend and frontend
Added complexity
Blurred responsibilities

40. 🤔

41. 🤔 😱

42. Why not a monolith?
Coupling between backend and frontend
Added complexity
Blurred responsibilities
Curiosity factor

43. Into the wild
Our apps grow

44. Into the wild
Our apps grow → potential next pain points

45. Into the wild
Our apps grow
AirHelp grows
→ potential next pain points

46. Into the wild
Our apps grow
AirHelp grows → new challenges with sharing components
→ potential next pain points

47. Into the wild
Our apps grow
AirHelp grows → new challenges with sharing components
Direction
→ potential next pain points

48. Into the wild
Our apps grow
AirHelp grows
→ potential next pain points
→ new challenges with sharing components
Direction → keep 🚀

49. Thank you