Tales of modernizing trello's web stack
0 likes•566 views
The document outlines the modernization efforts of Trello's web stack, highlighting the shift from aging technologies like CoffeeScript to more current tools such as React and TypeScript. It discusses various attempts at upgrading the front-end, including the challenges faced and strategies employed, including incremental transitions and enabling teams to adopt new technologies. Key takeaways emphasize the importance of establishing clear goals, understanding the complexities of rewrites, and fostering a culture of shared ownership and continuous improvement.
Tales of modernizing trello's web stack
- 1. Tales of Modernizing Trello’s web stack VINCENT KOK | ENGINEERING MANAGER | ATLASSIAN | @VINCENTKOK
- 2. Trello Engineering Manager at Trello About me @vincentkok Feel free to reach out Dutch You’ve probably already heard that ;)
- 3. React Solid industry standard and the default within Atlassian. TypeScript The winner in the typed JS space. Key technologies
- 4. DISCLAIMER! I’M AN ENGINEERING MANAGER AND MOSTLY BACKEND DEV :)
- 6. Why ? Tales from the past Tales from the present Tales from the future Agenda
- 7. The reason for modernizing https://flic.kr/p/aayTHr
- 8. TRELLO: WAS BUILT ON TOP OF THE LATEST TECHNOLOGY
- 9. Backbone First release 2010, 1 year old. Some tech decisions in 2011 Propriety build system Did what it needed todo, no other great alternatives. CoffeeScript First appeared in 2009, two years old.
- 10. After 9 years this tech is aging https://flic.kr/p/aAca95
- 11. Growing number of contributors
- 12. Invest in the future Viable long term tech stack. Talent We want to keep our talent engaged and explaining React is a better sell when hiring. Dev speed Maintaining the ability to ship and having the right dev experience is important. Performance Who doesn’t want to have a snappy UX? Drivers for a new tech stack
- 13. Simply a shift in where performance is easier and harder. DANIEL ANNESLEY - ATLASSIAN ENGINEER
- 14. ~200k LOC A non-trivial amount of code. 26 routes However, a lot of detail inside. Trello codebase
- 16. Tales from the past https://flic.kr/p/7qGxb1
- 17. Joel would tell people early on you gotta shoot gamma rays at Trello, mutate it and figure out what works and doesn’t, it’s ok if we shut something down. MICHAEL PRYOR
- 19. Upgrading the Trello Front-End https://flic.kr/p/8MrDrs
- 20. 3 Attempts
- 21. Attempt 1: Go Dark https://flic.kr/p/tJbJf5
- 22. Clean architecture No concessions. Focus No distraction for the team. No feedback Will be hard to ship for a long time. Feature parity Other teams will move forward. Go Dark: Pros and Cons
- 23. II
- 25. No Big-Bang Significantly reduced risk and something to aim for. Early feedback Get feedback on quality and milestones. Solve two problems Re-write and mixing old and new tech. Added complexity How to make sure we end up with this big mess? Incremental: Pros and Cons
- 26. ? How to implement the transition incrementally?
- 27. 6 options!
- 28. Criteria Industry Standard Make sure on boarding is simple, limit the amount of proprietary frameworks. Ship fast and often We want early feedback on the work we’re doing. DFTC Customers should not be aware of this. Dev Experience Working on the Trello Front-End is the best experience possible.
- 29. A CLEAR WINNER: PAGE LEVEL APPROACH
- 30. Step 1: Re-write the Header
- 31. Step 2: Route by route /:username/cards /b/:boardId /b/:boardId/c/cardId …
- 32. Just a simple matter of programming https://flic.kr/p/5Y5QPG
- 33. WRONG
- 34. Accidental patterns We didn’t have a process in place to establish patter, code was getting messy very quickly. Low velocity Team velocity wasn’t picking up, way behind our estimates.
- 35. Why were we failing? https://memegenerator.net/instance/59809489/why-suffering-guy-2-but-why
- 36. Shaky foundation The code we wrote earlier was becoming stale and not how we wanted to move forward. Technical reasons Pure architecture is and end-state Focus on a reasonable state and iterate. Establishing patterns is hard React seems simple but there are many ways doing the same thing, take time to build them out.
- 37. PICK ONLY ONE GOAL, THAT’S IT
- 40. Tales about the present https://flic.kr/p/8QULy5
- 41. BACK TO ONE GOAL ENABLE 2 OR MORE TEAMS TO USE NEW TECH TO WRITE FEATURES
- 42. Remember these?
- 43. Attempt 3: Leaves and Nodes https://flic.kr/p/aJ8Sx
- 45. One key component added GraphQL Going beyond REST, build for the future. React Solid industry standard and the default within Atlassian. TypeScript The winner in the typed JS space.
- 48. Render API Mix-in in React components into the “old” code base. State management State is managed via GraphQL, component don’t know anything about the Backbone models. Required API’s
- 55. Pit of success
- 56. Feature Team Continue to re-write some of the key elements. Front-End Platform team Focus on enablement. Split up our team
- 57. Onboarding and engagement Make it as easy to get started and create shared ownership. Front-End platform team Enable and Enforce Provide guardrails and scale out patterns via automation. Provide batteries Multiply the engineering team by providing them tools and API’s to ship features.
- 58. Establishing patterns Pause at one way doors Pause at hard to revert decisions, make them very deliberate. No abstraction over wrong one Do not abstract things away, there is nothing wrong with duplicating some code. Optimize for change You will learn and this will make you change how you do things.
- 59. Eligible ENGAMENT MODEL Consider limitation Establish patterns ENGAGE EMBED ENGINEERBuild out feature Technical design Team proficient
- 60. Share learnings Weekly meeting with all tech leads to discuss patterns, components, problems and learnings.
- 61. Create space to discuss direction and direct shared ownership FRONT-END FORUM
- 62. 2 Onboarding
- 63. Measure
- 64. Tales from the future https://flic.kr/p/rbEVPW
- 65. API API in place to allow team to focus on features. Continue to build the pit of success Tools Enable and enforce, continue to automate as much as possible. Scale We want to have autonomous teams, the high touch model does not scale
- 67. What should you take home? https://flic.kr/p/ocwc2h
- 68. Key takeaways You will underestimate You will find an enormous amount of depth in existing features, be careful with re-writes. Ideal architecture is an end- state Start with a reasonable state and iterate from there. Set one goal Do not conflate two goals as it will make it hard to make the right decisions. New technology is hard Establishing new patterns will take time to learn, start small and expand when you’re ready.
- 69. Thank you! VINCENT KOK | ENGINEERING MANAGER | ATLASSIAN | @VINCENTKOK