workflow driven development
TRANSCRIPT
Conway’s Law
organizations which design systems ... are constrained to produce designs which are copies of the
communication structures of these organizations
— M. Conway
More than skin deep
• Rethink UI/UX • Build a subset of the most important pages • Rewrite and do it right this time!
STAY AGILE
New web, new me
• Workflow perspective • Clear ownership of every single component • Independent dev teams
• Hence, workflow driven development
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
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?
Where we ended up
• Primary and secondary content • Client-side page composition • Isomorphic and semi-isomorphic JS apps
Primary content
• Page/URL is owned by specific dev team • Isomorphic JS apps • Semi-isomorphic JS apps
Secondary content
• Custom elements + HTML import on the client • client-side page composition • dynamic loading
• Independent delivery
Isomorphic JS
• Invented our own wheel (seed project) • React + Redux + ReactIntl + ReactRouter
• Babel for server-side code • Webpack for client-side code
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
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.