Team Isotopes: The speed demons of engineering
7.5.2018
Translation: machine translated
Pictures: Thomas Kunz
When it comes to raw speed, the Isotopes engineering team operates in a field of tension between man, machine and the future. They provide an insight into their work.
Damian Frizzi sits on the sun-warmed concrete blocks in front of the digitec offices. Sunglasses, grey T-shirt. He seems relaxed, speaks slowly, jokes from time to time and digresses from the topic. His topic is milliseconds, technology and a bit of oracy.
Damian is the Head of Frontend Engineering and a member of the team called "Isotopes", named after the baseball team of the fictional Springfield from "The Simpsons". He and his team of eight engineers work every day to make the shop even faster. They are not looking for the one thing that will eliminate delays of ten seconds, but milliseconds. If a process has not been streamlined so that not a millisecond of computing time is wasted, then that adds up on digitec.ch.
The Isotopes are currently working on a mammoth project: they want to reorganise the entire shop.
A look back in history: How shops worked in the old days
"In the prehistoric times of Web 1.0, websites worked differently than they do today," says Damian with a mischievous grin on his face. Because back then, around the end of the 1990s, this era came to an end. Prehistoric? Not at all. But still a long way off. People born in 1999 have been allowed to take their car test since last year. 1999 also saw the first use of the term "Web 2.0".
Web pages from back then work like this: You send a request to a website, the server calculates, the server sends you back a complete page. Then you click on a link, the server recalculates the page again and sends you another complete page. This means that every time you click on a website, a new page is loaded. This process is called page reloads or server side rendering (SSR) and may result in the user being sent data again that they have already requested. This leads to longer loading times when navigating the website.
Too slow for the user and far too slow for the isotopes.
This so-called server-side rendering was the best way to implement websites for a long time, as JavaScript was not yet as advanced as it is today. At the beginning of Web 2.0, however, JavaScript, whose purpose is to enhance the dynamics of websites, did not enable much more than image slideshows or date picker widgets.
As the years went by, the development of ever more powerful websites and visualisations pushed the traditional web to its limits. Today, customers expect fully featured application platforms. With fast JavaScript runtimes and HTML5 standards that display rich applications. In other words: everything you are used to from the internet. Because JavaScript and HTML5 are no longer a luxury, but the basics.
"That was the moment when developers changed their focus," says Damian. More and more computing power moved from the server to the client, i.e. to your computer. So-called single-page applications with client-side rendering enable direct interaction with the website without a diversion via the server.
Damian starts to explain: "Single-page applications are applications that are based on a minimal HTML structure and reload data - customised to the user and their environment - asynchronously in the browser."
So far that sounds good, but this is where the work of the isotopes begins. Even asynchronous data transfer, although faster than continuous server side rendering, brings obstacles, challenges and idiosyncrasies. Damian mentions the Google Crawler, a small programme that crawls the web for new content. It can only process client-side sites to a limited extent. Google's official recommendation is to display the relevant content of the page directly and not to reload it. Otherwise, there is a risk of downgrading the relevance and the page will appear further down in the search results.
Initial performance is also critical. As the entire Document Object Model (DOM), the architecture of a site, is built on the client, it takes a certain amount of time for the data to be requested, processed and rendered on the server.
"This can lead to long loading times, especially for clients with low computing power, old smartphones for example, or with a poor internet connection," says Damian.
This results in almost endless loading animations when the page is first loaded.
The isotopic path
The isotopes operate in this area of tension between user requirements - i.e. your requirements - and those of the technology. In addition: Google. The search engine giant naturally also has a say, whether it suits the Isotopes or not.
"We want a mixture of the new and the traditional approach: we want to return a fully-fledged HTML document from the server with the initial request so that the loading time remains as short as possible and Google and co. can continue to crawl our content in full," says Damian, taking a quick breath. He is in his element, talking fast and inhaling less. "But we also want to benefit from the performance boost of an SPA when navigating further within our application."
The Isotopes have sat down and experimented with universally renderable applications. In other words, whether human or crawler, the page makes sense and can be read, categorised and evaluated by a machine. To do this, the display logic must work perfectly on both a server and a client. That has its advantages.
"Not only do we save ourselves the additional work involved in developing for one environment, but we can also specifically control which content should be loaded and when," explains Damian.
To achieve this goal, two major problems need to be solved:
- Isomorphic Universal Frontend: Isotopes must build a frontend that can be processed and rendered by both a server and a browser and deployed to the cloud as an independent unit
- Data reload: You must be able to consume, temporarily persist and display data in the frontend from any independent interface
After experimenting and defining the requirements, wishes and limits, the team led by Damian Frizzi got down to business. Time to reinvent a web shop.
Universal front end
The Isotopes jump into the fray. The rendering engine is quickly determined: React, developed by Facebook. Both Facebook and Instagram use the JavaScript library and perform very well there. React, sometimes also called React.JS or ReactJS, supports rendering on the client and server side, has a large community behind it and is widely accepted by both humans and machines. It solves exactly one problem: rendering and therefore interaction with the DOM.
"Last but not least, React is very efficient. With a virtual DOM and targeted patches."
React is joined by Node.js on the server side. That makes sense, says Damian. This allows Isotopes to programme in JavaScript and benefit from existing expertise.
Data reload
APIs, i.e. programme interfaces, are the key to success when reloading data. The isotopes around Damian first have to catch up with the present here.
"We are currently converting all interfaces to web APIs," he says. He can barely suppress a sigh. Because the changeover is not easy. There are a large number of interfaces that need to be requested by the client. To prevent every user from having to send a huge number of requests to the digitec backend servers, we decided in favour of a GraphQL layer between the frontend and backend.
The advantages are clear: the client - i.e. the user's computer - only has to request one endpoint and the frontend developers do not have to deal with implementing the interface requests. The GraphQL server reduces the data to a minimum using queries and schema resolvers. This means that only the data that is actually required is exchanged between the client and the GraphQL server. This is a particular advantage with slow internet connections. Damian looks to the future: "We will later cache the data at the GraphQL level." This will reduce the number of requests to the interfaces and the client will receive an even faster response.
Speed. The isotopes are looking for them.
Damian summarises the core of digitec's current technology stack:
- JavaScript (ES2015, ES2016)
- Node.js
- React
- Next.js
- GraphQL
- Apollo
- Enzyme
- Jest
- Docker
- Azure
- Kubernetes
- ASP.NET Web API
This results in a prototype, which is where things get exciting.
A look at the prototype
"Confused? No problem. Take a look at this prototype," says Damian. The improved performance will only become apparent when it is seen.
Damian is proud: "And that's exactly what the isotopes do."
The result of the prototype will go online soon.
Apropos: Team Isotopes wants to let you know that our engineering team is looking for reinforcements. If you want to get involved, please take a look at the following open positions:
- Junior Software Engineer
- Software Engineer
- Senior Software Engineer
- Technical Lead / Cloud Architect
- Teamleader Software Engineering
In addition, there are other engineering positions here.
If you would like to find out more about how we develop, then take a look here.
Journalist. Author. Hacker. A storyteller searching for boundaries, secrets and taboos – putting the world to paper. Not because I can but because I can’t not.
