From API to Beautiful HX
6 June 2018
@picsoung
@typeform
Nicolas Grenié
Slide 2
Slide 2 text
Nicolas Grenié
@picsoung
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
40,000+
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
Monolith to Microservices
PHP to Golang+JS
Slide 8
Slide 8 text
Typeform’s roots
● PHP monolith app
● Strong UI/logic coupling
● Single MySQL database
Slide 9
Slide 9 text
Typeform’s problems
✖ Difficult to make changes
✕ UI/logic coupling
✖ Painful to make DB changes
✕ Migrations impact everything
✖ Inefficient scaling
✕ Just keep adding instances
Slide 10
Slide 10 text
Microservices transformation
✓ Separated key domains into
microservices, with separate databases
when possible
Examples:
○ Results
○ Forms
○ Themes
○ Images
✓ Built API proxy & auth systems
○ Javascript calls APIs directly
Slide 11
Slide 11 text
Investing in our future
→ Microservices built with:
○ Golang
○ A few Node services
■ More on this later
→ Able to scale independently
○ E.g. Results scales much differently
than forms
○ Distinct databases separates risks
Slide 12
Slide 12 text
Overhauled UX architecture
● HTML/Javascript/React
○ Form builder
○ Results
○ Form renderer (coming soon!)
● Launched “v2” in Feb 2018
○ Majority of UX using new principles
○ All new development using new
architecture
Slide 13
Slide 13 text
What could possibly go wrong?
Sounds perfect...
Slide 14
Slide 14 text
Too many API calls
On screens with lots of data…
● Javascript code has to make
many calls
● Poor performance
● Complex UX code
Slide 15
Slide 15 text
Backend for frontend
● UX dev-created
○ Node.js
○ Calls backend microservices/APIs
○ Consolidates many calls to one
○ BFF calls over private network (fast)
○ Produces UX-optimized payload
Service A
Service B
Service C
BFF UX
Slide 16
Slide 16 text
No content
Slide 17
Slide 17 text
Render one view = many API calls
Slide 18
Slide 18 text
With Backend for Fronted = 1 API call
Slide 19
Slide 19 text
From Microservices to Public APIs
Always ready to externalize
Slide 20
Slide 20 text
Spec-first development
● All microservices designed in OpenAPI
○ API design standards established
○ Specs are peer reviewed before
development
○ Additional data in custom fields:
■ Product/tech owner
■ Visibility
■ Development status
Slide 21
Slide 21 text
Spec-first development
● OpenAPI is “single source of truth”
○ Internal & public documentation
■ Generated from specs
■ Manually curated docs are
injected
○ API proxy
■ External APIs auto-configured
○ Auth system
■ OAuth scopes from specs
Slide 22
Slide 22 text
Built with Redoc https://github.com/Rebilly/ReDoc
Slide 23
Slide 23 text
Built with Gatsbyjs https://gatsbyjs.org
Slide 24
Slide 24 text
Designed to be public
● Microservices are designed using
customer domain language
● Always designed to be externalizable
(in principle)
○ No internal-only APIs*
● Unified auth system
○ Microservices understand JWT
regardless