Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Prototyping like it is 2022

•
•
Michael Yagudaev
Michael Yagudaev

Iterating and shipping software quickly to help you build what users want. Keeping it simple and scaling architecture over time, not right away.

1 of 89
Download to read offline
Michael Yagudaev Prototyping Like It’s 2022
About Michael • Indie Hacker @ conceptual.so (emojination.io), Skylab and picturethat.io • Full-stack Developer • Previous Life: UserTesting, Ollie Order, Consultant, PM, Founder, UX Designer, Corporate Employee • Web dev since 2001, professionally 2010 • O ffl ine: snowboarding 🏂, cycling 🚴 • 2022 Obsession: #BuildInPublic, marketing, YC Startup School
Prototyping like it is 2022
Outline • Generating Ideas • Exploring solutions • Dividing the work • Iterating and getting feedback
Where do we find ideas 💡? Product Market Fit
Audience First • 1. Find a group of people you want to help • 2. Find where they hangout • 3. Talk to them to fi nd an interesting problem • 4. Solve the problem • e.g. Talking to gamers about streaming and solving
 the problem of live streaming on multiple platforms
Problem First • 1. Brainstorm problems you encountered • 2. Pick an interesting recurring problem • 3. Solve the problem • e.g. Basecamp solved their own problem 
 of managing projects and clients
Solution First • 1. Pick a new solution space: Web 3.0, AR/VR, AI,
 new device/feature/API, etc • 2. Brainstorm problems you can solve • 3. Pick a problem that interests you • 4. Find the audience (ideally you are part of it) • 5. Build a solution • e.g. Markus Frind created POF to experiment with
 ASP.NET and pad his resume.
Why are you doing this? • Learning? • Make money? • Get a promotion? • Satisfy existing users? • Satisfy new users? • Intellectual curiosity? • Fun? • Good grade? • Get a job? • Simulated work experience?
Exploring the Solutions Space • Take a look at similar products • Search GitHub for libraries and API that can help • Take a look at demo projects on github or templates to get you started
Example: PictureThat • Explorered demos on Awesome ARKit • One of them was ARBrush
PictureThat • Paper Sketches
PictureThat • Showed sketches to my mentor • Challenged me to build it • Built it in one afternoon • July 14, 2017 - Tweet • Launched mid-Sep, 2017 on AppStore
Build something people want • 50% marketing/traction • 50% product
Clickable Mock up? • Figma / Framer • + Useful for quickly getting everyone on the same page • + Easier to do longer-term planning around • - Learning curve to design tool • - Users can’t use it to solve their problem, thus super fi cial feedback • - Easy to fi t too many features that can take years of development
Do you want to buy this?
Example: Emojination • Problem fi rst • Creating interesting job ads and 
 announcements • Inspired by headers.me • Weekend project React + Next.js + LocalStorage on Vercel
Why Prototype? • Faster Feedback loop • Get it to the hands of real users right away • Shouldn’t take more than a few days or weeks.
Early Stage Startup - Ollie • B2B Wholesale Platform for Alcohol • V1: Spree Commerce - Jan, 2019, created a marketplace to make it easier for buyers. No one wanted that. • V2: From scratch - March, 2019, 3 sr. devs (one played designer role) • React, Graphql, Typescript, Apollo, Rails, Postgres, Elastic-Search, Our own Design System • MVP: June, 2019, 3 sr. devs + 2 contractors • Sales Litre becomes part of Ollie - October, 2019 • PHP, Angular, RESTful API • V3: June, 2020 Rewrite • Rails, Stimulus Re fl ex/Hotwire, Postgres, TailwindCSS • 10 engineers, Jan 2021 • Sold July, 2021 NextGlass
Late Stage Startup - UserTesting • On-Demand usability testing enabling faster feedback cycles • V1: 2007 VB • V2: ~2010 Rewrite in Rails, Restful API, Angular.js • V3: Graphql, Angular, Typescript, Apollo, Rails, MySQL, Elastic-Search, Our own Design System • Ongoing splitting into Microservices • 200+ engineers, fi led IPO 2021
Skylab • Started Oct 2018 • Python, Rails, React, React Native, AWS • V1: 2018 Python ML • V2: 2019 Rails + Python • V3: 2020 React + Rails + Python • Engineering: 8 Engineers, 2 Teams — ML and Product
What do you need? • Fearless execution • Relentless common sense
Dividing the work • 1-person-army • Frontend vs backend • Full-stack by area • Pair Full-stack on an area • Clear the kanban board weekly • if someone fi nishes their tasks, help other teammates with theirs
Leadership • Product owner and project manager roles • Spend no more than 50% of the time on coding/design tasks
Iterate, Iterate, then Iterate again • Your product will be 💩 day 1 • Accept it and iterate relentlessly. • Ask people what it is 💩 for them • One day it will be 🐛 => 🦋 • Video about design iterations: Youtube Video
Easier to revise • Pick a good starting point • Simple • Addresses many of the requirements • Saves you time • Helps you focus on your unique value prop
Weekly Cadence • Talk to users • Write code • Each week write an update and deploy code
Start with the UI • Always start with the UI • Users sees and interacts with it • API is a UI for developers, if that’s your target user focus on that • Use a UI Kit or UI Starter Kit
UI Kits • Find a UI kit both you and your users like • https://chakra-ui.com/ • https://nativebase.io/ • https://divjoy.com/ • https://ant.design/ • https://mui.com/ • https://getbootstrap.com/
Try Pro/Templates UIs • Plenty of great Free templates • Consider buying pro, by pooling resources • e.g. $20/person • learn how authors write their code • Hustle: email the author, tell them your poor students. • Discount of free
Don’t overthink it • Find what works for you • Keep it simple • Code duplication is a feature, not a bug • Once you fi gure out the product based on feedback • You can eliminate some duplication
Talking to Users • Start talking to them day 0 • Figure out what they currently use and how they use it • Let them try your product • Capture their thoughts and feedback • Do this every week and their feedback to guide you
Conceptual.so • “AI” generated marketing images • 4-week YC startup school build sprint • Goal was to go beyond emojis (emojination.io) • Talked to 21 people, 15 signups • Focused on text => image after talking to people • Still need more traditional graphics capabilities like Canva and Figma offer
Prototyping like it is 2022
Analyzing User Interviews: Super Human https://review. fi rstround.com/how-superhuman-built-an-engine-to- fi nd-product-market- fi t What they love What is missing
Possible Web Architectures Map
Possible Web Architectures Map
1. No/Low Code
1. No-Code/Low-Code Architecture • Tools we can con fi gure to solve our problems • Categories: • 1. General Purpose hosted: Airtable, Bubble, GlideApps, Google Forms, NetSuite • 2. General Purpose self-hosted: Wordpress, ActiveAdmin, Strapi • 3. Website builders: SquareSpace, Web fl ow • 4. Specialized hosted: ForestAdmin, Twilio Studio, Algolia • 5. Specialized self-hosted: SugarCRM, Metabase, Odoo, SalesForce • 6. Integration: Automate.io, Zapier, ifttt, segment.io • 7. Web scraping: webscraper.io, ScrapeHero, ScrapeStorm
1. No-Code/Low-Code Architecture • Pros • Fast to start • No/little code to write • Less expensive then writing code • Continuously improves (receiving updates) • Uses best practices
1. No-Code/Low-Code Architecture • Cons • Learning curve • Never prefect fi t for your use case • Data silos in di ff erent tools • Vendor lock • No separate environments, staging/sandbox • No automated tests • testing tools like Ghost-inspector, solve that
Possible Web Architectures Map
2. Static-Site
2. Static-Site • Simple HTML + CSS & JS site, no server-side logic • Static site generators help on bigger sites: jekyll, hugo, middleman, … • JAMStack is newer addition • Javascript, Apis and Markup • Gatsby.js, Netlify, Next.js*, etc • Web apis exist for: login, shopping cart, cms, etc.
 
 
 * more capable
2. Static-Site • Pros • Simple • Uses web standards • Easy to build • Maximum fl exibility on look & feel • Low cost hosting • Lightweight bundles delivered to end-user
2. Static-Site • Cons • No direct access to dynamic data • Data silos between 3rd-party apis • Client-side only code, security challenges for APIs • Requires integrating many 3rd-party services • SEO needs to be considered (in contrast to e.g. Wordpress)
Possible Web Architectures Map
3. Frameworkless
3. Frameworkless • Idea: minimize use of 3rd party deps • Use language features and targeted libraries • e.g. using raw node http server, express, sinatra, fl ask, next.js* • can take approach on both client & server side
3. Frameworkless • Pros • Shallow learning curve • Minimal & fast system • Less things to go wrong • Cons • Integration burden is upon you • More custom code required • Limited community support (depending on language)
Possible Web Architectures Map
4. MVC Web Architecture
Prototyping like it is 2022
4. MVC Web-Architecture • Model-View-Controller one fi rst design patterns • Divides presentation and business logic concerns • HTML over the wire, i.e. server renders html (view layer) • Popular frameworks: Rails, Django, Sails.js, Play Framework, ASP.net Core, Phonix, Laravel, … • Refreshing data requires page reloads • Send updates via HTML Forms
4. MVC Web-Architecture • Pros • Simple mental model • Mature tech with good community support • Rapid development cycle • Fast initial load time • Simpler for SEO • Caching support: http caching, fragment caching, etc • Well integrated components*
4. MVC Web-Architecture • Cons • Certain UX pattern not possible without custom JS • Page redirects can make for awkward UX • Larger subsequent network requests • Network latency will make app feel sluggish (especially on mobile)
Possible Web Architectures Map
5. Reactive Server Architecture
Prototyping like it is 2022
5. Reactive Server Architecture • Builds upon MVC Architecture • Adds a fi ner grained reactive-loop • HTML response is di ff ed and changes applied • Uses web socket connection to minimize latency • Libraries: Stimulus Re fl ex, Hotwire/Turbodrive, Live View, Blazor Server, Socketpuppet, LiveWire
5. Reactive Server Architecture • Pros • No need for dedicated API layer • Business logic stays on server • Simple mental model, building upon existing one • Cons • Network latency • UI state kept on server • New and still early • (rails) poor isolation of component state
Possible Web Architectures Map
6. Client/Server Architecture (SPA)
UserTesting Direction • V3: Scaling engineering & product • Graphql, Angular, Apollo, Microservice/Microfrontends, Ruby/Rails, Go, other languages • 200+ engineers and growing • Slowly going away from Monolith
Prototyping like it is 2022
6. Client/Server Architecture (SPA) • Client: in-charge of UI rendering • Server: in-charge of data fetching + business rules • Build explicit interface for communication • REST • Graphql • RPC • SOAP • Transport medium: HTTP or Websockets
6. Client/Server Architecture (SPA) • Pros • Decouples UI from Data • Max fl exibility on client • Simple to understand • Cons • Requires dedicated API • Requires syncing state • Duplication of logic — potential mis-match
Ollie in June, 2020
Ollie Direction • V3: Simpli fi cation - June, 2020 • Tailwind, Stimulus Re fl ex, Rails, Database search, Our own design system • January, 2021 - fully replaced SPA with Reactive-Server Architecture
Ollie in June, 2020
UserTesting in March, 2021
Skylab in Oct, 2021
Possible Web Architectures Map
7. Microservices Architecture
Prototyping like it is 2022
7. Microservices Architecture • Breakdown backend monolith • Each piece is an isolated process, either on the same or separate node • Communication is done via Sockets, HTTP or event bus • Protocols can be REST, gRPC, ProtocolBu ff , graphql • Origin from Service Oriented Architecture (2000-2010) • Serverless architecture is part of it
7. Microservices Architecture • Pros • Independent deployability & scalability • Simpler & independent code bases • Can use many di ff erent languages • Easier to assign teams with clear boundaries • Cons • Hard to test entire system • Hard to change boundaries • Tracing errors across system becomes more di ffi cult • Compounding latency when services call each other • DevOps complexity
Possible Web Architectures Map
8. Micro Frontends
Prototyping like it is 2022
8. Micro Frontends • Breakdown frontend monolith • Container application manages mounting/unmounting of UIs • Pulled down at runtime
8. Micro Frontends • Pros • Independent deployability UI + backend • Incremental upgrades • Simple independent code bases • Autonomous cross-functional teams • Cons • Increase download size • Inconsistency in UI between teams • Devops complexity • Environmental di ff erences between prod and dev
Possible Web Architectures Map
9. Exotic Architectures
9. Exotic Architectures • Newer tech useful in speci fi c situations • List • CQRS/Event Sourcing • GraphDBs - e.g. Neo4J • Block-chain / Web3.0
Conclusion Keep calm and iterate
One more thing… • Participate in the community as you are learning • Post your wins/struggle, get inspired by friends • Twitter #100DaysOfCode or #LearnInPublic • Huge help when looking for a job • Twitter is for Devs, Linkedin for hiring managers
References • https://martinfowler.com/articles/microservices.html • https://martinfowler.com/articles/micro-frontends.html • Clean Code - Robert Martin • Clean Architecture - Robert Martin • https://www.wired.com/2015/09/whatsapp-serves-900-million-users-50- engineers/ • https://review. fi rstround.com/how-instagram-co-founder-mike-krieger-took- its-engineering-org-from-0-to-300-people
Questions? Twitter/Linkedin: @yagudaev Website: yagudaev.com

More Related Content

Prototyping like it is 2022

  • 2. About Michael • Indie Hacker @ conceptual.so (emojination.io), Skylab and picturethat.io • Full-stack Developer • Previous Life: UserTesting, Ollie Order, Consultant, PM, Founder, UX Designer, Corporate Employee • Web dev since 2001, professionally 2010 • O ffl ine: snowboarding 🏂, cycling 🚴 • 2022 Obsession: #BuildInPublic, marketing, YC Startup School
  • 4. Outline • Generating Ideas • Exploring solutions • Dividing the work • Iterating and getting feedback
  • 5. Where do we find ideas 💡? Product Market Fit
  • 6. Audience First • 1. Find a group of people you want to help • 2. Find where they hangout • 3. Talk to them to fi nd an interesting problem • 4. Solve the problem • e.g. Talking to gamers about streaming and solving
 the problem of live streaming on multiple platforms
  • 7. Problem First • 1. Brainstorm problems you encountered • 2. Pick an interesting recurring problem • 3. Solve the problem • e.g. Basecamp solved their own problem 
 of managing projects and clients
  • 8. Solution First • 1. Pick a new solution space: Web 3.0, AR/VR, AI,
 new device/feature/API, etc • 2. Brainstorm problems you can solve • 3. Pick a problem that interests you • 4. Find the audience (ideally you are part of it) • 5. Build a solution • e.g. Markus Frind created POF to experiment with
 ASP.NET and pad his resume.
  • 9. Why are you doing this? • Learning? • Make money? • Get a promotion? • Satisfy existing users? • Satisfy new users? • Intellectual curiosity? • Fun? • Good grade? • Get a job? • Simulated work experience?
  • 10. Exploring the Solutions Space • Take a look at similar products • Search GitHub for libraries and API that can help • Take a look at demo projects on github or templates to get you started
  • 11. Example: PictureThat • Explorered demos on Awesome ARKit • One of them was ARBrush
  • 13. PictureThat • Showed sketches to my mentor • Challenged me to build it • Built it in one afternoon • July 14, 2017 - Tweet • Launched mid-Sep, 2017 on AppStore
  • 14. Build something people want • 50% marketing/traction • 50% product
  • 15. Clickable Mock up? • Figma / Framer • + Useful for quickly getting everyone on the same page • + Easier to do longer-term planning around • - Learning curve to design tool • - Users can’t use it to solve their problem, thus super fi cial feedback • - Easy to fi t too many features that can take years of development
  • 16. Do you want to buy this?
  • 17. Example: Emojination • Problem fi rst • Creating interesting job ads and 
 announcements • Inspired by headers.me • Weekend project React + Next.js + LocalStorage on Vercel
  • 18. Why Prototype? • Faster Feedback loop • Get it to the hands of real users right away • Shouldn’t take more than a few days or weeks.
  • 19. Early Stage Startup - Ollie • B2B Wholesale Platform for Alcohol • V1: Spree Commerce - Jan, 2019, created a marketplace to make it easier for buyers. No one wanted that. • V2: From scratch - March, 2019, 3 sr. devs (one played designer role) • React, Graphql, Typescript, Apollo, Rails, Postgres, Elastic-Search, Our own Design System • MVP: June, 2019, 3 sr. devs + 2 contractors • Sales Litre becomes part of Ollie - October, 2019 • PHP, Angular, RESTful API • V3: June, 2020 Rewrite • Rails, Stimulus Re fl ex/Hotwire, Postgres, TailwindCSS • 10 engineers, Jan 2021 • Sold July, 2021 NextGlass
  • 20. Late Stage Startup - UserTesting • On-Demand usability testing enabling faster feedback cycles • V1: 2007 VB • V2: ~2010 Rewrite in Rails, Restful API, Angular.js • V3: Graphql, Angular, Typescript, Apollo, Rails, MySQL, Elastic-Search, Our own Design System • Ongoing splitting into Microservices • 200+ engineers, fi led IPO 2021
  • 21. Skylab • Started Oct 2018 • Python, Rails, React, React Native, AWS • V1: 2018 Python ML • V2: 2019 Rails + Python • V3: 2020 React + Rails + Python • Engineering: 8 Engineers, 2 Teams — ML and Product
  • 22. What do you need? • Fearless execution • Relentless common sense
  • 23. Dividing the work • 1-person-army • Frontend vs backend • Full-stack by area • Pair Full-stack on an area • Clear the kanban board weekly • if someone fi nishes their tasks, help other teammates with theirs
  • 24. Leadership • Product owner and project manager roles • Spend no more than 50% of the time on coding/design tasks
  • 25. Iterate, Iterate, then Iterate again • Your product will be 💩 day 1 • Accept it and iterate relentlessly. • Ask people what it is 💩 for them • One day it will be 🐛 => 🦋 • Video about design iterations: Youtube Video
  • 26. Easier to revise • Pick a good starting point • Simple • Addresses many of the requirements • Saves you time • Helps you focus on your unique value prop
  • 27. Weekly Cadence • Talk to users • Write code • Each week write an update and deploy code
  • 28. Start with the UI • Always start with the UI • Users sees and interacts with it • API is a UI for developers, if that’s your target user focus on that • Use a UI Kit or UI Starter Kit
  • 29. UI Kits • Find a UI kit both you and your users like • https://chakra-ui.com/ • https://nativebase.io/ • https://divjoy.com/ • https://ant.design/ • https://mui.com/ • https://getbootstrap.com/
  • 30. Try Pro/Templates UIs • Plenty of great Free templates • Consider buying pro, by pooling resources • e.g. $20/person • learn how authors write their code • Hustle: email the author, tell them your poor students. • Discount of free
  • 31. Don’t overthink it • Find what works for you • Keep it simple • Code duplication is a feature, not a bug • Once you fi gure out the product based on feedback • You can eliminate some duplication
  • 32. Talking to Users • Start talking to them day 0 • Figure out what they currently use and how they use it • Let them try your product • Capture their thoughts and feedback • Do this every week and their feedback to guide you
  • 33. Conceptual.so • “AI” generated marketing images • 4-week YC startup school build sprint • Goal was to go beyond emojis (emojination.io) • Talked to 21 people, 15 signups • Focused on text => image after talking to people • Still need more traditional graphics capabilities like Canva and Figma offer
  • 35. Analyzing User Interviews: Super Human https://review. fi rstround.com/how-superhuman-built-an-engine-to- fi nd-product-market- fi t What they love What is missing
  • 39. 1. No-Code/Low-Code Architecture • Tools we can con fi gure to solve our problems • Categories: • 1. General Purpose hosted: Airtable, Bubble, GlideApps, Google Forms, NetSuite • 2. General Purpose self-hosted: Wordpress, ActiveAdmin, Strapi • 3. Website builders: SquareSpace, Web fl ow • 4. Specialized hosted: ForestAdmin, Twilio Studio, Algolia • 5. Specialized self-hosted: SugarCRM, Metabase, Odoo, SalesForce • 6. Integration: Automate.io, Zapier, ifttt, segment.io • 7. Web scraping: webscraper.io, ScrapeHero, ScrapeStorm
  • 40. 1. No-Code/Low-Code Architecture • Pros • Fast to start • No/little code to write • Less expensive then writing code • Continuously improves (receiving updates) • Uses best practices
  • 41. 1. No-Code/Low-Code Architecture • Cons • Learning curve • Never prefect fi t for your use case • Data silos in di ff erent tools • Vendor lock • No separate environments, staging/sandbox • No automated tests • testing tools like Ghost-inspector, solve that
  • 44. 2. Static-Site • Simple HTML + CSS & JS site, no server-side logic • Static site generators help on bigger sites: jekyll, hugo, middleman, … • JAMStack is newer addition • Javascript, Apis and Markup • Gatsby.js, Netlify, Next.js*, etc • Web apis exist for: login, shopping cart, cms, etc.
 
 
 * more capable
  • 45. 2. Static-Site • Pros • Simple • Uses web standards • Easy to build • Maximum fl exibility on look & feel • Low cost hosting • Lightweight bundles delivered to end-user
  • 46. 2. Static-Site • Cons • No direct access to dynamic data • Data silos between 3rd-party apis • Client-side only code, security challenges for APIs • Requires integrating many 3rd-party services • SEO needs to be considered (in contrast to e.g. Wordpress)
  • 49. 3. Frameworkless • Idea: minimize use of 3rd party deps • Use language features and targeted libraries • e.g. using raw node http server, express, sinatra, fl ask, next.js* • can take approach on both client & server side
  • 50. 3. Frameworkless • Pros • Shallow learning curve • Minimal & fast system • Less things to go wrong • Cons • Integration burden is upon you • More custom code required • Limited community support (depending on language)
  • 52. 4. MVC Web Architecture
  • 54. 4. MVC Web-Architecture • Model-View-Controller one fi rst design patterns • Divides presentation and business logic concerns • HTML over the wire, i.e. server renders html (view layer) • Popular frameworks: Rails, Django, Sails.js, Play Framework, ASP.net Core, Phonix, Laravel, … • Refreshing data requires page reloads • Send updates via HTML Forms
  • 55. 4. MVC Web-Architecture • Pros • Simple mental model • Mature tech with good community support • Rapid development cycle • Fast initial load time • Simpler for SEO • Caching support: http caching, fragment caching, etc • Well integrated components*
  • 56. 4. MVC Web-Architecture • Cons • Certain UX pattern not possible without custom JS • Page redirects can make for awkward UX • Larger subsequent network requests • Network latency will make app feel sluggish (especially on mobile)
  • 58. 5. Reactive Server Architecture
  • 60. 5. Reactive Server Architecture • Builds upon MVC Architecture • Adds a fi ner grained reactive-loop • HTML response is di ff ed and changes applied • Uses web socket connection to minimize latency • Libraries: Stimulus Re fl ex, Hotwire/Turbodrive, Live View, Blazor Server, Socketpuppet, LiveWire
  • 61. 5. Reactive Server Architecture • Pros • No need for dedicated API layer • Business logic stays on server • Simple mental model, building upon existing one • Cons • Network latency • UI state kept on server • New and still early • (rails) poor isolation of component state
  • 64. UserTesting Direction • V3: Scaling engineering & product • Graphql, Angular, Apollo, Microservice/Microfrontends, Ruby/Rails, Go, other languages • 200+ engineers and growing • Slowly going away from Monolith
  • 66. 6. Client/Server Architecture (SPA) • Client: in-charge of UI rendering • Server: in-charge of data fetching + business rules • Build explicit interface for communication • REST • Graphql • RPC • SOAP • Transport medium: HTTP or Websockets
  • 67. 6. Client/Server Architecture (SPA) • Pros • Decouples UI from Data • Max fl exibility on client • Simple to understand • Cons • Requires dedicated API • Requires syncing state • Duplication of logic — potential mis-match
  • 69. Ollie Direction • V3: Simpli fi cation - June, 2020 • Tailwind, Stimulus Re fl ex, Rails, Database search, Our own design system • January, 2021 - fully replaced SPA with Reactive-Server Architecture
  • 76. 7. Microservices Architecture • Breakdown backend monolith • Each piece is an isolated process, either on the same or separate node • Communication is done via Sockets, HTTP or event bus • Protocols can be REST, gRPC, ProtocolBu ff , graphql • Origin from Service Oriented Architecture (2000-2010) • Serverless architecture is part of it
  • 77. 7. Microservices Architecture • Pros • Independent deployability & scalability • Simpler & independent code bases • Can use many di ff erent languages • Easier to assign teams with clear boundaries • Cons • Hard to test entire system • Hard to change boundaries • Tracing errors across system becomes more di ffi cult • Compounding latency when services call each other • DevOps complexity
  • 81. 8. Micro Frontends • Breakdown frontend monolith • Container application manages mounting/unmounting of UIs • Pulled down at runtime
  • 82. 8. Micro Frontends • Pros • Independent deployability UI + backend • Incremental upgrades • Simple independent code bases • Autonomous cross-functional teams • Cons • Increase download size • Inconsistency in UI between teams • Devops complexity • Environmental di ff erences between prod and dev
  • 85. 9. Exotic Architectures • Newer tech useful in speci fi c situations • List • CQRS/Event Sourcing • GraphDBs - e.g. Neo4J • Block-chain / Web3.0
  • 87. One more thing… • Participate in the community as you are learning • Post your wins/struggle, get inspired by friends • Twitter #100DaysOfCode or #LearnInPublic • Huge help when looking for a job • Twitter is for Devs, Linkedin for hiring managers
  • 88. References • https://martinfowler.com/articles/microservices.html • https://martinfowler.com/articles/micro-frontends.html • Clean Code - Robert Martin • Clean Architecture - Robert Martin • https://www.wired.com/2015/09/whatsapp-serves-900-million-users-50- engineers/ • https://review. fi rstround.com/how-instagram-co-founder-mike-krieger-took- its-engineering-org-from-0-to-300-people