Download as PDF, PPTX
Uploaded byFITC
Building Enterprise Grade Front-End Applications with JavaScript Frameworks
This document discusses best practices for building enterprise-grade front-end applications using JavaScript frameworks, including aspects like framework selection, scalability, and testing. It emphasizes the importance of a structured approach to application architecture, highlighting popular frameworks like Angular and React, and the significance of tools for continuous integration and automated testing. Additionally, it covers deployment platforms, hybrid applications, and the critical role of performance and reliability in enterprise environments.
Building Enterprise Grade Front-End Applications with JavaScript Frameworks
- 1. Building Enterprise GradeFront-End Apps with Javascript Frameworks
- 2. Chad Upton • Senior Consultant @ DEV6 •Developing websites for 20+ years • Won Webby Award and W3 Award • Wrote Adobe’s Advanced Video Course Leaders in Enterprise Web Applica2ons and Full- Stack Development Training DEV6.com @dev6tweet@chadupton
- 3. Outline • Choosing aFramework • Platforms • Testing • Reviewing and Reporting • Scale • Performance • DevOps
- 4.
- 5. What does thateven mean? Enterprise • Complex • Scalable • Distributed • Component-Based • Mission Critical
- 6. Complex? • jQuery isgreat for small apps and utilities within large apps • Making a small app complex does not make it Enterprise • Complex is not the goal • Complex is a result of a feature rich application • Complex is maintainable when the code is well organized
- 7. Scalable • Grow withuser volume • Grow beyond a single • database • app server • etc
- 8. Distributed • Grow withuser distribution • Grow beyond a single data center location • Cross platform
- 9. Component-Based • More testable •More iterative • Easier to update • More collaborative • More maintainable
- 10. Mission Critical • Appis down, revenue is down • App stability reflects image of business • Quality
- 11.
- 12.
- 13. What is aFramework? • Vehicle that takes a project from start to finish • You pilot the vehicle successfully (or not) • Reusable abstractions that help structure application • Vary in rigidity or opinion/freedom • Recipe for building an application • Standardization for current and future collaborators • Toolset for previously solved problems
- 14. Why use aFramework?
- 15. Quality Application Strong Foundation InvisibleWork Visible Results
- 16. Component-Based 80% Frameworks drive component-based architecture, makingapps more: testable, iterative, updatable, collaborative and fixable
- 17.
- 18. The Perfect Framework •No perfect framework • You will always require more or less • Closest fit for your architectural style • Not going to be perfect here either • Has most features your project needs • Compatible with other features needed
- 19. Project Needs • Localization? •Internationalization? • Reusable Components? • Template Syntax? • Dependency Injection? • Module loading? • etc
- 20. Framework or DIY •Multiple libraries may give you more flexibility • Multiple libraries could be smaller/ faster than one large framework • One framework that does everything will likely have fewer problems down the road
- 21. Tooling • Code generator •Build scripting/helper • IDE Integration • Easy to deploy/test locally
- 22. Popularity • Community ofdevelopers • 3rd Party Components • Training • Books • Official Support
- 23.
- 24. Angular • Huge developercommunity • 3rd party components • Training, Books, Tutorials, Examples • Good documentation • Official support from Google
- 25. Angular 2 Features •Router • Code Splitting/Module Loading • Dependency Injection • Animation • Ahead-of-Time Compilation • Testing framework • Browser Inspector • Command Line Interface (CLI)
- 26. React • Nearly asmany features as Angular • More of a library than a framework • Inline components/templates • Less opinionated than Angular • More 3rd party libs usually required • Routing, Testing, etc • Smart diff rendering (fast)
- 27. Backbone • Library, notframework • Underscore.js • jQuery • Router • Data Bindings • Unopinionated • No Logic in HTML • No HTML in Code
- 28. Ember.js • Similar toAngular, full framework • Router • Testing Framework • Inspector (browser add-on) • CLI with code generation • Dependency Injection • Persistent services
- 29.
- 30.
- 31. Platform Criteria • Whois going to use your app? • How are they going to use it (ex. offline)? • What kind of devices do they have? • Are web browsers capable enough? • Does your app need GPS? • etc…
- 32. Platform Environments • Desktop/Laptops •Mobile Phones/Tablets • Kiosks • Set top boxes • etc…
- 33. Platform Types • WebApp • AKA “Progressive Web App” • Hybrid Mobile App • Packaged for iOS, Android, etc • Hybrid Desktop App • Package for Windows, Mac, etc
- 34. Web App • ClientProcessed • Most common type of web app in use • Easy to build, update and serve • HTML, CSS, JavaScript + Frameworks, Libraries, etc • Server Processed • Varying degrees of server processing • Server may process CSS, State and/or layout, all the way to: • Page looks to web browser like a static HTML page
- 35. Server Processed • Bettersearch indexing than Client Processed Single Page Applications • Initial render typically faster than client processed • Fewer downloads/network operations • Some content is pre-rendered • Favorable to teams with greater backend skills
- 36. • Angular • node.js,PhantomJS • React • node.js, C#/ASP.NET, Nashorn (Java) • Backbone • Rendr = Open source option from AirBNB Server Processed Frameworks
- 37. Mobile Browser Optimized •Responsive and Adaptive Design • Layout is programmed to change based on screen/window size • Best for Search Engine Optimization • Dynamic Serving • Server renders different layout/content based on screen size • Separate URLs • Mobile users directed to a mobile website • Not recommended
- 38. Hybrid Mobile App •Packaged for iOS, Android, etc • Created with HTML, CSS, JavaScript, Frameworks, Libraries, etc • Container tool to embed web app in a native mobile container • Typically installed from Google Play, Apple App Store, etc…
- 39. Why Hybrid MobileApp? • Leverage existing web skills or code • Need additional capabilities of a mobile app • Update UI, Logic, Data without submitting updates through store • Not all scenarios allowed on all platforms
- 40. Hybrid Mobile AppPackagers • Cordova • Free and OpenSource • Adobe PhoneGap • Cordova + more tooling, plugins, services • Ionic Framework • Build on Angular, Runs in Cordova or PhoneGap • Cloud services • NativeScript
- 41. NativeScript • Real nativeapp • Not a web app • Web content and controls converted to native content and controls • One codebase matches native apps • Controls look and work exactly like native controls, because they are!
- 42. Hybrid Desktop App •Package web for Windows, Mac, etc • Like Adobe Air, without Flash Player • Great for rapid prototyping • Leverage existing markup and code • Don’t have the same limitations of browser • File system access • Relaxed cross domain policy
- 43. Hybrid Desktop AppSolutions • Electron (by GitHub) • Windows, Mac, Linux • Built on Node.js, Chromium • NW.js • Leverage node modules from DOM • More Chrome Apps and API support • AppJS • No longer under development
- 44.
- 45. Benefits of Testing •Match design specifications • Catch regression • Think like a user • Find bugs before users do • Reduce cost • Improve quality
- 46. Types of Tests •Functional/On device • Load testing • User Observation • Acceptance • Unit • Integration • End-to-End
- 47. Manual Testing • Functional •Ensure correct function • Load Testing • Verify acceptable user quantity • User Observation • Improve user experience • Acceptance • Meets all requirements (final before release)
- 48. Automated Testing • UnitTests • Test isolated“unit” of code (ex. a function) • Integration Tests • Test units interaction with each other • End-to-End Tests • Simulate user and test complete application flow from start to finish
- 49. Automated Testing • TestSuite • Collection of automated tests • Easy to run, run often! • Before, During, After coding • Test Driven Development • Write tests then code to test • Write once, run on multiple devices • Budget time for testing
- 50. Testing Tools • Selenium •Karma - Unit/Integration • Protractor - End-to-End • Jasmine, Mocha, QUnit • Keynote • Rent real mobile devices in cloud • Many more…
- 51.
- 52. Review code andperformance during submission and deployment
- 53. Code Reviews • Mentoror Senior Developer • Frequently • Each submission, each feature • Talk about • Why • Alternatives • Best ways to continue learning: • Syntax, Performance, Logic, Debugging, etc
- 54. Automated Bug Reporting •Catches JavaScript Errors • Stores errors in cloud • Notifications • Best • Metrics • Breadcrumbs • Map files for useful stack traces • Mark as resolved
- 55. Logging • DVR foryour application • Log as much as possible • Include logs with bug reports • Who was the user? • Where in the app were they at the time? • Where have they been? • What data was received from server?
- 56.
- 57. Reliable Applications Work Everywherefor Everyone
- 58. Reliability • Scalable • Distributed •Broad Device Support
- 59. Scalability • Load testfirst and often • ex. BlazeMeter • Use CDNs for assets and libraries • Consider a reliable Proxy • ex. CloudFlare • Own your CDN content • Own your APIs if possible • Cache public APIs if you can’t own them
- 60. Distributed • Regional Servers •Not a replacement for scalability • Each Region Should Scale • Cloud Infrastructure • Amazon Web Services • Google Cloud Platform • Azure, OpenStack, etc…
- 61. Broad Device Support •People want to use everywhere • Desktop, Phone, Tablet, etc • Minimize decisions that will limit where application can be used • Phone will soon be primary device for majority of users
- 63.
- 64. Performance • Well builtapplications are fast • Performance is a feature • Reduce data transfer and requests • Minimize code • Modularize code • Compress images • CSS Sprite Sheets
- 65. Performance • Look fora fast framework • React • Angular 2 • Measure speed before/after each • major code addition • major change/refactor • Use framework best practices • Play with and Measure different solutions
- 66.
- 67. Software Development + Software DeliveryProcess = Development Operations
- 68. Development Operations • CodeManagement • Continuous Integration • Automated Testing • Package • Release • Configuration • Monitoring
- 69. Code Management • SourceControl • Git, SVN, Mercurial, Perforce… • Branch Code • Branch Process • Automation • Boilerplate/Generator • ex. Angular-CLI
- 70. Source Control • GitPreferred • GitHub • BitBucket • Continuous Integration • Branch and Release Process • GitFlow
- 71. Continuous Integration (CI) •Brings everything together… • Compile code • Minimize Code • Compress Images • Run automated tests and linting • Send failure notifications • Dashboards • Store build metrics
- 73. Continuous Integration Products •Jenkins (free, open source) • TeamCity • Bamboo/Pipelines
- 74.
- 75. • Angular 2 •Angular CLI • BugSnag + Mixpanel • ng-bootstrap • Jasmine, Karma, Protractor • Bitbucket + Bamboo Preferred Front-End Stack
- 76. • Culture ofQuality • Test driven development • Code reviews • Observe users • Automate bug collection • Own CDN and API • Use fast framework • Measure and analyze performance • Budget time for all of these things! Best Practices SUCCESS
- 77. sales@dev6.com 1-866-464-7790 Leaders in EnterpriseWeb Applications and Full-Stack Development Training DEV6.com @dev6tweet