Uploaded byAnurag Sinha
Building Large Scale Web Apps And Platforms
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.
![Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/apachesparkgettingstarted-260203175547-8361bcc3-thumbnail.jpg?width=640&height=640&fit=bounds)
Building Large Scale Web Apps And Platforms
- 1. BUILDING LARGE SCALE WEBAPPS AND PLATFORMS 1
- 2.
- 3. STUFF I AMGONNA RAMBLE ABOUT... ▸ A little background ▸ Platform centric approach ▸ Architectural Patterns 3
- 4. TRADITIONALLY... ▸ Disjoint webapps 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
- 6.
- 7. PATTERN 1: SEPARATEOUT INITIAL RENDERER 7
- 8. ▸ Serve differentfront 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: OPTIMIZEINITIAL RENDERING ▸ Intelligent first load ▸ Server side rendering ▸ Early load data 9
- 10. PATTERN 3: MICRO..(ER?) SERVICES 10
- 11. ▸ Design coreoperations as Micro-Services ▸ Spectrum of Concerns: From Resource To Operations ▸ Stateless Services ▸ Good Ole' SRP (Single Responsibility Principle) 11
- 12. PATTERN 4: FACADEABSTRACTS OPERATIONAL CONCERNS 12
- 13. ▸ Generic concernssuch 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: ASYNCWHERE YOU CAN... ▸ Non blocking communication ▸ Increases decoupling in the stack ▸ Lessen impact of errors in dependencies ▸ Preserves autonomy 14
- 15. PATTERN 6: CACHESTRATEGICALLY... ▸ Front end clients ▸ Facade layer ▸ Core Services design 15
- 16. PATTERN 7: SINGLELAYER OF ABSTRACTION BETWEEN RESOURCES 16
- 17. ▸ Optimal separationbetween 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: STATEIS 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: MOCKITYMOCK MOCK.... 20
- 21. ▸ Mock stubsat 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 ▸ BuildGeneric APIs ▸ Kill State ▸ Separation of Concerns (& Resources) ▸ Context Sharing ▸ Scalable and Faster development cycles 22
- 23.
- 24.
- 25.