Building large scalable mission critical business applications on the web
•Télécharger en tant que PPTX, PDF•
0 j'aime•563 vues
![Maurice De Beijer [MVP]](https://cdn.slidesharecdn.com/profile-photo-mauricedb-48x48.jpg?cb=1696317804)
Building large scalable mission critical business applications on the web presentaion for React Remote Conf 2016
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Building large scalable mission critical business applications on the web
Similaire à Building large scalable mission critical business applications on the web (20)
Plus de Maurice De Beijer [MVP]
Plus de Maurice De Beijer [MVP] (20)
Dernier
Dernier (20)
Building large scalable mission critical business applications on the web
- 1. Building large scalable mission critical business applications on the web Maurice de Beijer @mauricedb
- 2. Safety in hard to reach places 2
- 3. Who am I? • Maurice de Beijer • The Problem Solver • Microsoft Azure MVP • Freelance developer/instructor • Twitter: @mauricedb and @React_Tutorial • Web: http://www.TheProblemSolver.nl • E-mail: maurice.de.beijer@gmail.com 3
- 4. Overview • HTTP and Ajax requests • Scaling out • Programming language and code quality • Webpack • Error logging and collection • Dates and times
- 5. HTTP is hard
- 6. Swagger for HTTP contracts
- 7. Chaos Monkey • Http request have a tendency of failing • Simulate this behavior when developing
- 8. Retry on errors • Retry requests that fail • After a brief pause
- 9. HTTP Caching is hard • Caching static data can help performance – But cache invalidation is hard • Use the HTTP vary header – Accept header – Authorization header
- 10. Scaling out
- 11. Scaling out is hard • When going to the second server – But easy going from the second to the third
- 12. Chaos Monkey • Middleware to randomly route all requests to a different server when developing
- 13. Writing Code
- 14. TypeScript • Or use another type checker like Flow
- 15. ESLint & TSLint • Use ESLint and/or TSLint • Use eslint-plugin-react for React code • Airbnb publish a great configuration – The eslint-config-airbnb NPM package
- 16. Webpack
- 17. Webpack CommonsChunkPlugin • Build shared library bundles just once – Using DllPlugin& DllReferencePlugin – Better performance then using the CommonsChunkPlugin
- 18. HappyPack • Speed up Webpack builds – Use Awesome Typescript Loader for TypeScript
- 19. Error logging • Errors will happen • Don’t assume you are online
- 20. Errors in React components
- 22. Dates and times • Working with date and time is hard – Specially when objects are moving – Having to coordinate across multiple time zones
- 23. Moment.js • The best library for working with dates • Use Moment Timezone to convert to individual timezones
- 24. Conclusion • HTTP and Ajax requests can be unreliable – Specially on remote and mobile connections • Scaling out – Isn’t hard if you do so from day one • Programming language and code quality – JavaScript and JSX is fine for small projects – Big projects need more help • Webpack is awesome – But rebuild times add up with a large codebase • Error logging and collection – Error will happen – Make sure you know about them • Dates and times – Can be very tricky – Use moments.js for time zone conversions and formatting
- 25. Thank you Maurice de Beijer - @mauricedb
Notes de l'éditeur
- Deepwater Horizon Offshore Drilling Platform on Fire https://www.flickr.com/photos/ideum/4711481781
- https://www.flickr.com/photos/quinnanya/5046072204/
- Do contract first developments Generate the client and server side DTOs
- HTTP in the wild is tends to fail occasionally Specially for mobile and satellite connections Request will complete in a different order then started Make sure this already happens during development https://www.flickr.com/photos/87913776@N00/460181144/
- With HTTP Status codes >= 500 you can retry Polly will help you
- Always add cache headers Use Etags for larger objects that change over time Add a content hash or version number to js/css/images files https://www.flickr.com/photos/nodespt/6101496060
- Scaling from 1 to 2 servers I shard From 2 to around 10 is easy Above 10 it becomes hard again https://www.flickr.com/photos/orangebrompton/224649987
- Always run with at least 2 servers during test and QA Chaos load balancer randomly picks a server per request https://www.flickr.com/photos/87913776@N00/460181144/
- https://www.pexels.com/photo/coffee-writing-computer-blogging-34676/
- TypeChecking is extra work in a small app But a life saver in a big app Makes refactoring much easier
- Linting is similar to type checking but finds a different type of error Some rules like number of spaces to indent is not that important But consistency helps a lot Other rules like declaring variables an React props are much more important
- Webpack is an awesome bundeler Used to trigger Babel and TypeScript Using presets: es2015, stage-0 and react
- The CommonsChunkPlugin is easy to use but keeps being evaluated The DllPlugin just builds once and it’s static manifest is reused
- HappyPack caching can greatly speed builds of large code bases Also use multiple threads for parallel builds
- Add a global error handler Log your errors to the server Also store in LocalStorage or IndexedDB in case the server is unreachable Bundle identical errors in a time slot to prevent a lot of HTTP traffic Don’t forget to log HTTP and Promis errors
- Runtime errors in React lifecycle methods is really bad Dan Abramov created react-transform-catch-errors which is a good alternative but only does render functions.
- Make sure errors are very clear during development. But maybe a bit less so in production
- http://www.flickr.com/photos/torley/2705966678
- https://www.flickr.com/photos/stevendepolo/4582437563/