This is a proof of concept for using web components as microservices on the frontend. It consists of four different services (timer-controls, timer-display, style-guide and inline-input), plus a glue layer to stitch things together.
# Make sure you have yarn installed
scripts/install
scripts/start --openThe only fairly complex service around here – handling interactions while setting up the talk. Written in Elm. Elm’s ports and flags play together with the custom elements API wonderfully, so wiring this up was a breeze.
To mount it without the rest of the app, run timer-controls/scripts/mount --open. You can pass the --debug flag to see some Elm goodness.
Written in React as an ES5 script without a build step. A pleasure to write the component itself, but wiring this up as a custom element required a minimal amount of manual state management.
To mount the microservice on its own, run timer-display/scripts/mount --open.
Most apps running on frontend microservices have a single, lightweight style guide under the hood. It’s making sure the whole app feels consistent.
This one is super rough, just a few lines of global CSS. A real-world example would surely be more involved, but probably still kept low-tech. Just like Zalando’s dress-code.
We’ve also had a go at writing a component in pure JS. No framework, no architectural conventions, no build. As close to the bare metal as it gets.
Turned into quite a blob of spaghetti code. Interesting as an experiment, but we wouldn’t recommend this in a large-scale project.
The app shell is written in pure JS. All it’s about is setting up input data and wiring together the outputs and inputs of services.
Wiring services together is incredibly simple.
To roll this out as quickly as possible but still make it feel nice, we picked some ready-made Polymer elements. They’re super easy to use in any of the technologies we built the services (Elm, React, vanilla JS, vanilla HTML) – and they’re done nicely. They deliver native-like performance even on a crappy old low-end phone. The tradeoffs are: they weigh a ton, plus they use bower.
But hey, look at it from the other side! Even though we pull down three runtimes (Polymer, React, Elm) and half the jungle, the app is usable immediately! As different bits and pieces arrive, parts of the app upgrade to become usable. That’s one of the great wins when using web components as microservices.
present.now.sh is served over HTTP/2, so unless you’re using an ancient browser it should be just about as fast as one request of the same size.
The upside of having everything in separate requests lies in performance again. Halfway through loading time, you have half the app usable. If we served everything over a single request, we’d have to wait for everything to be downloaded, then parsed, then executed before we could start using the app.
MIT © Lystable