Building Large Scale Web Apps And Platforms
3 likes1,256 views
The document outlines strategies for building large-scale web applications and platforms, emphasizing a platform-centric approach and architectural patterns. Key patterns include optimizing initial rendering, using microservices, and strategically caching, all aimed at improving scalability and development efficiency. The text also highlights the importance of adhering to specifications and maintaining separation of concerns to enhance system robustness.
Building Large Scale Web Apps And Platforms
- 1. BUILDING LARGE SCALE WEB APPS AND PLATFORMS 1
- 3. STUFF I AM GONNA RAMBLE ABOUT... ▸ A little background ▸ Platform centric approach ▸ Architectural Patterns 3
- 4. TRADITIONALLY... ▸ Disjoint web apps and services stacks ▸ Server Side State management ▸ Mostly monolithic codebases ▸ Duplication of Platform logic 4
- 5. PLATFORM CENTRIC APPROACH... ▸ Single Page Applications ▸ Blurring the line between Web Apps & APIs ▸ Reuse at scale ▸ Truly centralised server architecture ▸ Thinking in terms of platform capabilities 5
- 7. PATTERN 1: SEPARATE OUT INITIAL RENDERER 7
- 8. ▸ Serve different front ends while reusing core biz logic ▸ Isolate experience state to initial renderer ▸ Enforce homogenous contract for core services ▸ Unified platform to serve experiences and APIs 8
- 9. PATTERN 2: OPTIMIZE INITIAL RENDERING ▸ Intelligent first load ▸ Server side rendering ▸ Early load data 9
- 10. PATTERN 3: MICRO..(ER ?) SERVICES 10
- 11. ▸ Design core operations as Micro-Services ▸ Spectrum of Concerns: From Resource To Operations ▸ Stateless Services ▸ Good Ole' SRP (Single Responsibility Principle) 11
- 12. PATTERN 4: FACADE ABSTRACTS OPERATIONAL CONCERNS 12
- 13. ▸ Generic concerns such as Authorization, Validation, Logging can be abstracted by a facade ▸ Maps resources for internal vs external clients & APIs ▸ Can Orchestrate calls to multiple core services ▸ Can act as a robust layer to keep the core platform generic. 13
- 14. PATTERN 5: ASYNC WHERE YOU CAN... ▸ Non blocking communication ▸ Increases decoupling in the stack ▸ Lessen impact of errors in dependencies ▸ Preserves autonomy 14
- 15. PATTERN 6: CACHE STRATEGICALLY... ▸ Front end clients ▸ Facade layer ▸ Core Services design 15
- 16. PATTERN 7: SINGLE LAYER OF ABSTRACTION BETWEEN RESOURCES 16
- 17. ▸ Optimal separation between internal and external resources. ▸ Multiple external resources can map to a single internal resource. ▸ Designing internal resource as a super Resource has its pitfalls. ▸ Facade layer can abstract away the right concerns in order to not pollute the internal resources. 17
- 18. PATTERN 8: STATE IS A NECESSARY EH..(?)VIL ! " # ▸ Manage state at the client or the facade layer ▸ Context sharing between core services can happen via shared request interfaces ▸ Statelessness enables generic use and decreases points of failures ▸ React.JS and Angular.JS allow pushing the state to clients 18
- 19. PATTERN 9: ADHERE ! TO A SPEC ▸ Enforces strict contract ▸ Makes each service independently testable and deployable ▸ Makes the whole stack framework/language agnostic ▸ Spec frameworks provide a lot of tools out of the box 19
- 20. PATTERN 10: MOCKITY MOCK MOCK.... 20
- 21. ▸ Mock stubs at each layer ▸ Lesser dependence on environment for testing ▸ ECI pipelines run and certify all use cases ▸ Front end clients ▸ End to End Stack regressions 21
- 22. KEY TAKEAWAYS ▸ Build Generic APIs ▸ Kill State ▸ Separation of Concerns (& Resources) ▸ Context Sharing ▸ Scalable and Faster development cycles 22
- 23. Questions ? 23
- 24. Thank You! 24
- 25. 25