Front End Architecture — Part 1
in theory
Intro — the What?
In the middle of October I attended the O’Reilly Software Architecture conference in London. As a front end developer this was not an obvious choice but as someone who is always open to learning new things it seemed like a good opportunity. Going through the schedule of the event it was already clear that it is not going to be the go-to source of state of the art “frontendy” — yes it is a word — best practices. It will be more like
Let’s talk about microservices… again! YAY… wait, what?
But after the initial shock it turned out that there were many other things to listen to like talks about serverless architecture or the organisational aspects of being a software architect. The importance of the latter and the low number of front end topics (basically 2 and a half) made me think that it would be good to start a conversation (even if it is only with myself) about how web architecture is transforming and why we need to start talking more about where the front end fits into our systems (on top, obviously).
The Times They Are a-Changin’ — the Why?
As you can see on the graph above the average JavaScript size for the top 100 sites between 2010 and 2017 went from ~80 kB to ~460 kB with no signs of stopping (a.k.a. Souders’s law). This means that we move more and more business logic from our back end to the front end. So it seems like a good idea to think about the ways we can make this as performant and as maintainable as possible.
Historically our systems on the web (at least the ones most of us web developer created) were back end heavy, meaning that most of the architectural decisions we needed to make were in that domain. Kind of like, here is the data, don’t worry about how I got it, just render something that the designers dreamed about, like tables or divs or whatever you dynamically typed gangsters are into these days. If your website is still like that, please stop reading this article immediately… now that we lost .00001% of the readers let’s look at some practical problems.
One of my “favourite” and “simplest” problem that you usually face in the world of web development is form validation. This happens to be the earliest of real use cases of JavaScript as well. So you don’t want to send your form and its data every time to the server just so that you can tell your users that the email field is required, right? So you need to implement validation rules in two different systems and somehow keep them in sync. This is already a hard problem to dive into at the whiteboard with your fellow and favourite backend dev and create some elaborate (a.k.a. over-engineered) solution. Clearly this is only the tip of the iceberg, let’s not go into the custom styling of native form inputs people write PhD theses about (or books like this or this) but that is also a great opportunity to involve the designer (a.k.a. UX) in the conversation.
Once you overcome all these obstacles, the good news is that you already involved a couple of people in the conversation who might have one or two insight because of their background or previous experience and you also learned a thing or two about their domain. Cooperation rulez.
And how about a bit more complex problem like making your application offline first? For this to work you might need to watch and memorise everything you can find about service workers, PWAs and anything that Jake Archibald writes, talks or tweets about (WOW… that IS a lot). However what you can — and I believe you should — do is talk to a mobile app developer, they have been dealing with this for years now if not decades so they will definitely be able to shed some light on the gotcha’s and best practices like the app shell.
There is another interesting topic for front end architecture to think about, which is the more enhanced visualisation of our data and UIs like graphs, animations and the probably the most demanding one: gaming. Here you might need to read up on WebGL, WebAssembly and WebRTC. You should also talk to people who have experience in the performance implications of JavaScript being (mostly) single threaded and how to potentially get around it using WebWorkers.
Help the Coyote — the How?
If you want to make God laugh, tell him about your plans. — Woody Allen
So what’s next? How do we do this? I’m exhausted already!!! Well, the good old answer comes to mind: It depends. It depends on the specifics of your domain and your UX goals. You might need to consider very different solutions if you are dealing with a webshop (most of us) with SEO requirements or a web version of Duke Nukem (Yay!!!).
In general there are a couple of ideas that are considered good practices like single atomic state (Redux, RxJS Store) and unidirectional data flow both of which are arguably more about dev experience and maintainability than performance or user experience in general. Still, they are crucial for understanding what is going on in your codebase (and for you to stay sane).
When it comes to animations it is usually a good idea to try to prioritise everything UI related above all non-UI related activities like tracking, fetching your data or saving the user’s state into the client’s storage just to mention a few. You can use requestIdleCallback for such events and requestAnimationFrame for animations, except that idle callback is not yet supported too widely (only Firefox and Chrome). If you don’t like this solution, you can try setTimeout with a random delay and pray to the browser gods that you won’t hit the middle of a scroll event.
Let’s talk first render. Most of the websites use some source for their data (third-party services, DBs) and in many cases this is your bottleneck. Try to make this async and render something for the users while they wait. You can use server side rendering and inline styles for the core of your application and stream everything else asynchronously. If you are dealing with a lot of different clients (support for Playstation and intelligent toasters) you should check out Relay and graphQL that can make this a bit easier to maintain.
How about the second render and caching? Most of the time your goal is to keep users and build your brand. Well, if you can, you should take advantage of service workers and if your data is mostly useful and accurate, even if it is a bit stale, just show it and ask your data provider what’s new. Once you have things to update try to do it as gracefully as possible, maybe even ask your users if they want to see it so that they are not in the middle of something when you try to re-render things.
Unit testing — I wanted to leave this topic for last as it doesn’t exactly come to mind when you think about software architecture. Although in my experience TDD can help you a lot in this area and lead to a much healthier codebase because of the constant refactoring of your code to make it easy to test. Note that I have seen bad quality code with 100% coverage as well, so like everything else, this is also not a silver bullet. A while ago, I saw this inspiring talk from Rich Hickey in which he talks briefly about tests and suggests that you should generate them and they should only run once. If you haven’t seen it I highly recommend it and everything else from him.
Summary — the TL;DR!?!
No matter what kind of application you develop it could use some architectural planning from a front end perspective. Don’t forget that you are not the first person to face the problems you might encounter no matter what they are. Talk to your fellow developers and designers and see if there are best practices you can reuse in your domain. When it comes to offline first apps you might turn to native app developers because they know one thing or two about the app shell. When it comes to animations you can learn a lot from game developers. Lastly, if you start a new project or sitting on a legacy codebase full of bugs it is always a good idea to get together with product and UX / designers and identify (clear up) your common components across your site and create a dynamic (or static) style guide in the process.
Furthermore — the …
In part 2, I plan to share some code examples and diagrams for the architectures I mentioned. Meanwhile here are some random inspiring videos about front end and software architecture in general.
Random quotes
We will always going to be wrong eventually and there is nothing wrong with that, and we should plan for that. — Zach Tellman
If you have data, let’s use that. If you only have opinions, then let’s use mine. — Jim Barksdale
Which frontend framework will we regret using in 6 months?
https://medium.com/@atikenny/front-end-architecture-part-1-5-f3653d8c7fdd
