The Past, Present, and Future of Web Apps

Transcript

1. Web Apps - Past, Present, and Future
2. A brief evolution of web apps
3. Late 90s - the beginning • Primitive interactivity moving beyond pure static presentation of data • IE4 released in 1998 - first time easy to manipulate DOM, add classes, positions, etc • Webmail one of the first “web apps”. • Cross browser JavaScript a nightmare. • Conventional wisdom to keep all code on the server if possible
4. The Next Generation • Rails influential in making building web apps much easier • jQuery changed the way we think about DOM manipulation and event handling. • New browsers erode IE domination. • .NET emerges within MS community • AJAX becomes commonplace • Browser compatibility still a headache.
5. Modern Era • Single page web apps become standard practice. • Major browsers all close to parity with auto-updating. • Mobile web eclipses desktop web in importance. • Explosion in screen sizes, responsive UIs nearly mandatory.
6. Adiós plug-ins. HTML from here on • As the web has grown up, browser plug-ins that filled functionality gap are being phased out.
7. Bright Future Ahead Web Components Web RTC Web App Manifest ES6 Mobile Web Performance Service Workers AngularJS 2.0
8. New Way of Thinking about Front-End • To take advantage of all the modern web has to offer, a new way of architecting web apps is needed. • It’s no longer about enhancing server rendered templates with some jQuery sugar • Front-end apps should be thought of as a new standalone entity. • Just serve up an index page with static assets and let the browser do the rest. • Ideally “Single page applications” will become the deficit for web apps and the name will die off.
9. Splitting Up Monolithic App Backend App Front-end App JSON / CORS / Web Sockets http://api.app.com http://app.com • To take full-advantage of front-end powered apps, what formerly would likely have been built as a single monolithic app in .NET, Rails, etc. become two physically separate apps. • Independently built, and independently released • Decoupled via RESTful service interfaces. • Backend can be implemented in any language - Ruby, Python, C#, Java, node.js, etc. • Front-end is JS+HTML+CSS. • Service-oriented architecture means a native app front-end can share same API.
10. Anatomy of a SPA 1 - load url Browser • In a single page app, step 2 only happens once
11. Anatomy of a SPA 1 - load url 2 - GET / App Server Browser • In a single page app, step 2 only happens once
12. Anatomy of a SPA 1 - load url 3 - <html> 2 - GET / App Server Browser • In a single page app, step 2 only happens once
13. Anatomy of a SPA 1 - load url 3 - <html> 2 - GET / App Server Browser CDN 4 - GET js, css, images • In a single page app, step 2 only happens once
14. Anatomy of a SPA 1 - load url 3 - <html> 2 - GET / App Server Browser CDN 4 - GET js, css, images API 5 - GET data • In a single page app, step 2 only happens once
15. Anatomy of a SPA 1 - load url 3 - <html> 2 - GET / App Server Browser CDN 4 - GET js, css, images API 5 - GET data 6 * - interact • In a single page app, step 2 only happens once
16. Anatomy of a SPA 1 - load url 3 - <html> 2 - GET / App Server Browser CDN 4 - GET js, css, images API 5 - GET data 6 * - interact 7 * - POST data, GET more • In a single page app, step 2 only happens once
17. Why Build this Way? Happy users Agility Forces SOA Embrace the Web • End users like apps that feels snappy and smooth • By decoupling from the backend, the front-end is liberated to iterate and release more quickly • Service oriented architecture means better re-use and greater ability to adapt over time • Harness the full power of advances in browser technology
18. Why Not? More difficult Crawl-ability Browser compatibility • More difficult and more complexity - more moving parts with APIs. Modern frameworks have lowered the bar considerably. • Special steps required in order for search bots to get at all content. Google starting to crawl AJAX. • Old IE still a potential deal killer
19. Opinionated recipe for new apps
20. Step 1 - Pick a Framework Current Leaders Up and Comers • Start with the client framework, not the server. The client app framework is the scaffolding for your app on which everything else is supported. • App is characterized not as a .NET, or Rails, app, but as an Angular or Ember app. • Might be temptation to start simple with jQuery and vanilla JS, but resist, it’s harder to retrofit in a framework later. • Remember “you’re always using a framework, even if it’s your own”
21. Step 2: Responsive HTML5 Framework Others: • Semantic UI • Pure • uikit • Ionic • Make it responsive from the get go. • Unless you are a CSS guru, establishing basic CSS foundation built from scratch is a major undertaking and you won’t get it right the first time. • Most include widgets for buttons, grids, modals, tooltips, forms, and more. • Look for something that plays nicely with your selected JS framework. • Yes page bloat is a consideration, might consider custom builds. • My personal go-to is Angular-UI Bootstrap and stylus. • Looking forward to new Foundation for Apps that integrates with Angular
22. Step 3: Workflow Toolchain Build tool Test runner Test Framework Source Control Continuous Integration / Delivery Package manager • Need a build tool to prep assets, run pre-processors • Frameworks like Angular make unit testing client JavaScript much more pleasant • Prefer npm over bower, node is already required by gulp and grunt anyway • Apply the same rigor to front-end delivery as has been traditionally focused on the backend.
23. Step 4 - Pair with a Backend(s) Custom API 3rd Party API BaaS + Thousands More • Ideally all APIs are CORS enabled for direct browser communication
24. Step 5: Hosting Static Hosting Cloud PaaS VM Bare Metal Or something new?? • Bare metal entails the most DevOps and sys admin, oftentimes only solution for on-premise deployments behind firewall • Cloud PaaS provides elasticity and automation of many DevOps functions like auto-scaling, deployments, logging, dashboards, etc. Have to write at least a minimal backend. Multiple dedicated VMs overkill for minimal compute resources required to serve static assets. • Static hosting is free or very cheap. But no managed services beyond deployments.
25. Introducing Aerobatic CDN OAuth API Gateway CLI Traffic Control Dashboard Dev Ops Complexity EC2 GitHub Pages SEO Logging Custom Domains SSL • PaaS purpose built for front-end web applications. • Right mix of capabilities and ease of use • Targeted at developers building modern, agile web front-ends
26. Don’t Reinvent the Wheel Purpose built for new breed of front-end apps Works in conjunction with grunt / gulp / npm Use the frameworks you love - Angular, Sass, Bootstrap, LESS, Ember, and so on. Encourages service oriented architecture Best practices baked in DEMO
27. David Von Lehman @davidvlsea david@aerobatic.com www.aerobatic.com