Single Page Apps: What an API Developer Should Know
summary
Eight months leading a front-end team building an Angular client uncovers concrete tradeoffs: deploy SPA bundles statically (S3) while the API must enforce real-time authorization, handle state sync vs client-side Redux/RxJS stores, and support XSRF protection. An edge API can aggregate calls and hold credentials but can be abused. Server-side rendering (React/Vue) helps SEO not security. Favor additive-only versioning to avoid simultaneous client/back-end upgrades and expect polling or WebSockets for live updates.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:08Why API developers should learn SPAs
- 3:14SPA architecture overview
- 5:31SPAs static deployments and routing
- 7:25Security challenges in SPAs
- 12:22State management in APIs
- 17:31SPA architecture for APIs
- 20:00Edge APIs for SPA integration
- 22:17Guiding principles for API teams
- 24:31Breaking development silos
- 26:58Conclusion
related talks
10mUniversal Apps: Architecture for the Modern Web
28mSingle Page Applications - was it a good idea?
01h 07mGreat single page apps need great backends
40mFRONTEND CHOICES
13mHow to Survive the Single Page App-ocalypse
48mSecurity Risk: Single-Page Applications.
24mBuilding Realtime Singlepage Apps
31mDecoupled, Not Disconnected: State and Sync in Micro-Frontends
