The web community is a fast moving community and over the recent years, many great frameworks and tools have emerged. Technology changes made in the past are not always the right ones today. This applies to Trello’s web stack too. CoffeeScript and Backbone were great choices 7 years ago but there are better tools and frameworks available now, so the Trello team decided to update its stack. But, how does one tackle this and how do you make sure you continue to innovate product-wise while modernizing its web stack? This is what we will discuss in this session -- main drivers for modernizing, the reasoning for choosing for TypeScript, React and GraphQL and will discuss our strategy implementing it, including two failed attempts. When leaving this session you will have learned which tactics to apply when modernizing a web stack and warning signs to be aware off.

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 :)

5. REACT SPRING
FRAMEWORK

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

15. Trello is realtime

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

24. Attempt 2: Incremental
https://flic.kr/p/48V2XX

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

38. YOU WILL
UNDERESTIMATE

39. Don’t do rewrites

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.

47. Batteries
included

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

49. <GammaComponentWrapper/>

52. No GraphQL
Server
support

53. Front-End GraphQL only

54. Enablement is key
https://flic.kr/p/6xZAmc

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

66. Cleanup
https://flic.kr/p/nXpuSh

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