Connecting with the user
We build systems that need to withstand high peak loads, without failing or noticeably degrading in service level. Add to this that our scoreboards are very low latency – in fact delays need to be put in place for them not to ruin the excitement by announcing goals before the live TV stream has shown them. This places a lot of non-functional demands on UI components. The UI also needs to be intuitive and good looking, both on the outside and the inside.
Mitigating the mess
High scalability, low latency, ever changing frameworks, API versioning, multiple server resources, dynamic typing etc. are usually quite conducive to expediting the forming of a real mess, particularly in the eyes of those not on the original roster. Considering this, it feels only natural to also have the future custodians in mind.
Apart from making an effort to keep our code clean and have it convey its intent as clearly as possible, we scour the internet for nice frameworks to aid us along the way.
In its current form, push is being done using HTTP/2 after a quick flirt with Websockets. And by introducing an API query language we can relieve the client of a majority of the API-calls. This is particularly nice as very rarely do higher, more maintainable abstractions, naturally lead to better performance.
Few things have changed as often as frontend architectures and technologies in recent years. And while there are legions of nice ways of solving the hello world case, the vast majority of them eventually fall apart at higher complexity problems. Thus far we have been happy using the Backends for Frontends pattern – and so far it looks like fate is not going to spring any nasty surprises on us.
Particularly in the user facing space, technologies are bound to come and go. So far we have had many and significant problems solved – and very few new ones created – by employing the following:
- Apollo client