$30 off During Our Annual Pro Sale. View Details »

From API to Beautiful HX

From API to Beautiful HX

Typeform's story on how we transition to monolith to microservices APIs

https://blog.apimatic.io/an-evening-with-api-evangelists-8be2c621f3fa

https://www.youtube.com/watch?v=3sgBO1vKsLc

Nicolas Grenié

June 06, 2018
Tweet

More Decks by Nicolas Grenié

Other Decks in Technology

Transcript

  1. From API to Beautiful HX 6 June 2018 @picsoung @typeform

    Nicolas Grenié
  2. Nicolas Grenié @picsoung

  3. None
  4. 40,000+

  5. None
  6. None
  7. Monolith to Microservices PHP to Golang+JS

  8. Typeform’s roots • PHP monolith app • Strong UI/logic coupling

    • Single MySQL database
  9. Typeform’s problems ✖ Difficult to make changes ✕ UI/logic coupling

    ✖ Painful to make DB changes ✕ Migrations impact everything ✖ Inefficient scaling ✕ Just keep adding instances
  10. 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
  11. 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
  12. 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
  13. What could possibly go wrong? Sounds perfect...

  14. Too many API calls On screens with lots of data…

    • Javascript code has to make many calls • Poor performance • Complex UX code
  15. 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
  16. None
  17. Render one view = many API calls

  18. With Backend for Fronted = 1 API call

  19. From Microservices to Public APIs Always ready to externalize

  20. 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
  21. 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
  22. Built with Redoc https://github.com/Rebilly/ReDoc

  23. Built with Gatsbyjs https://gatsbyjs.org

  24. 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
  25. Why? So you get great APIs :)

  26. Thanks! http://bit.ly/TF-talk-apimatic @picsoung @typeform