This project aims to assist chaos engineers in thinking about creating robust UI experiences that can survive massive service outages successfully. The project intends to focus on modular architecture that pretends to be informed by microservices. It also intends to build out robust redundancy with service workers and fallbacks for critical routes.
- Break 3rd party tool - using error boundaries.
- Make NY Times fail, for real this time.
- Bring down the server, keep the browser running
In the beginning we had spacejam and Bob Dole. These were sites that are essentially devoid of any javascript and relied on html sent from a server. The only state on a website was contained within form input fields. Compariatively, the state management concerns and the associated complexity of javascript applications today have barely any respemblance to the website experiences of yesteryear. The introduction of single page applications (SPAs) as well as dramatic increase in the capabilities of the browser mean that the state management concerns for a user session have moved in a large part, from the server to the client. A recent example would be the introduction of codesandbox which allows developers to write, share and execute code on the cloud.
- WebAssembly (WASM)
- A new type of code that can be run in modern browsers.
- A compilation target for languages languages such as C, C++ and Rust.
- Highly perfomant and great for 3D games, Virtual and Augmented Reality, computer vision, image/video editing
- Service Workers
- A control mechanism for caching data and redirecting network requests
- serviceworke.rs
- HTTP/2.0
- Improved Latency
- Data compression for http headers
- Server Push
- Multiplexing multiple requests over TCP connection
- Improved Latency
- Micro Frameworks
Users always have a motive for loading a page in their browser. In thinking about creating a robust UI, it's important to seperate that motive from supplimentary information that, though useful to them, is not imperitive to the outcome they seek. Some infomation can be ommitted if unavailable or treated differently. For critical paths where omission is obviously not a possibility, suggesting alternative ways for the user to accomplish their objective may be possible or some apology and admission of failure.
If third party assets are being used on critical flows in the user interface, they should be consider potential weaknesses in the critical path of the application. In the event that these assets fail, the user will most likely attribute blame to your organization. Creating fallback redundencies for third-party assets may be a way to mitigate away these concerns.
React.js, Ember.js and Vue.js and Anglular all have error handling methods to handle catching errors and providing alternative state. Today we are going to throw some errors and see what happens!
Request Blocking can be used as a mechanism to see how your application responds to failure
- Has to be served over HTTPS, (also works in development)
- Normally abstracted away for development mode by default because of issues on reload
- The ability to retrieve cached index.html, javascript, css assets.
- The ability to create an embedded fallback strategy if resources are unavailable
- The ability to load balance based on server availability
- Go To https://codecupcake.com/
- Application Level Failure to experiment with UI outcomes in production
- The abilities to target specific clients gives us the ability to test real world scenarios with a higher degree of certainty.
- Building Robust UI in development with tooling that allows UI devs to replay real-world failure modes to test against.
Patrick Higgins
This project is licensed under the MIT License