Developing large scale web applications is challenging enough on its own. It gets even trickier when development should be done by several independent teams responsible for their own product areas and UI design implies that their work is tightly integrated and should be perceived as one product. Workflow driven development is about how we at Nordnet decided to address these issues, what frontend architecture solutions we’ve decided to adopt to allow our teams to work independently and still deliver common product we call next.nordnet.

2. Workflow Driven Development
One does not simply build a new web
by Dmitry Demyankov

3. So what is Workflow Driven
Development?
Hint: I made it up

4. Conway’s Law
organizations which design systems ... are constrained
to produce designs which are copies of the
communication structures of these organizations
— M. Conway

5. Nordnet IT History
Monolith IT structure
Large code base
Unclear ownership

6. WE MUST DO FEATURES

7. BUT WE HATES IT!

8. From waterfall to agile
Pipes - dev teams
Separate product areas
Separate code base

9. More than skin deep
• Rethink UI/UX
• Build a subset of the most important pages
• Rewrite and do it right this time!
STAY AGILE

10. New web, new me
• Workflow perspective
• Clear ownership of every single component
• Independent dev teams
• Hence, workflow driven development

11. So what did we come up with?
• Client - Browsers, pure client-side JS
• Server - NodeJS, server-side rendering
• API - Middleman for our backend services
• Pure Backend - Services and databases

12. How could it be done?
• How do backend devs do it?
• Microservices!
• How do frontend devs do it?
• SPA monolith
• Dynamic runtime - multiple <scripts/>
• ESI, other solutions for page composition?

13. Where we ended up
• Primary and secondary content
• Client-side page composition
• Isomorphic and semi-isomorphic JS apps

14. Primary content
• Page/URL is owned by specific dev team
• Isomorphic JS apps
• Semi-isomorphic JS apps

15. Secondary content
• Custom elements + HTML import on the client
• client-side page composition
• dynamic loading
• Independent delivery

16. Isomorphic JS
• Invented our own wheel (seed project)
• React + Redux + ReactIntl + ReactRouter
• Babel for server-side code
• Webpack for client-side code

17. Isomorphic vs semi-isomorphic
• Send only JS that is needed on the client
• e.g. dynamic content
• Different React root elements for server and client
• Not exactly progressive enhancement

18. Summary
• Organisational structure could be affecting your
product and architecture choices
• Think about your dev teams and how they should fit in
whatever architecture you might enforce on them, the
workflow should work for you not not you for it.
• Choose tech stack that supports your UI/UX,
development workflow.