Reimagine Frontend in the Serverless Era

Hello, everyone. This is Evangelia. I'm the tech founder and creator of Fioromat Academy, an upskilling academy for frontend engineers. Today, we will talk about how serverless technologies are impacting frontends. Initial spark for this talk was from my former employer, Elastic, where there were lots of developments for the lower level of the architecture in search index and the backend transformation.

However, what does this mean to us, the frontend, the consumption layer? These are a few words about myself, my most recent milestones. I have been almost 20 years in the tech industry. Okay. What is serverless? Does it mean that there is no server? Not actually. It's a misleading word.

Does it mean there is no backend? Actually, backend is changing. It's becoming more lightweight. It's becoming stateless backend. This is what it means. In a few words, it means that the backend is split into stateless, ephemeral units, but we don't manage them anymore.

Let's quickly see how the serverless architecture is operating to then understand the impacts on frontend. We are still the customers, the creators, the builders of the app. But this time, our code talks to an API gateway, but it's not the same API like it used to be in the traditional architectures. The API gateway acts as a router to the smaller serverless functions, not to large endpoints that they are returning huge JSON files that they used to do. It makes sure that it does it in a secure and scalable way. So the serverless functions and the code of this architecture are smaller business units without any state that we still the customers write and own, but the cloud provider is in charge of hosts and scaling keys.

However, we pay them as you go, only when we use them. That means if they became idle for a while, it takes a while to restart them. That's why we end up in cold start situations, similar to how the engine in a car works. And the last is the persistent layer, the database. We still design the data model and the queries for the app. However, the cloud provider is in charge of managing and scaling it. All right. What does this mean to us for frontend? The state is being shifted to frontend and to database layers, actually. We own more state, actually.

What does this mean? We take the initiative sometimes to update the state on the browser before waiting for the final confirmation from the backend. This is the optimistic updates. When do we usually optimistically update the state? When we want instant feedback from the UI, like when we make likes, comments, start a message, and you can see on the code here that we set the state before the try. And if it fails, we can roll back at any time on the catch.

Another impact in architectural frontend is that caching strategies become critical. We do have so far caching in global state managers, but now it's really critical. It's important, besides the in-memory that we cache it so far in Redux and other technologies. In this architecture, we cache it on the local storage. In this way, we reduce HTTP API calls because, as we saw before, we might run into cold start situations, which means that the backend might be delayed on responding cache. We still cache the data, but we don't want to make sure they become stale and outdated.

A third implication is that the connection handling, which is the HTTP call, the actual call that we make, becomes and should become resilient. There is a higher probability in this architecture for the HTTP call to fail because of network requests, because of the cold start that we mentioned earlier. That's why we have the option to retry the API calls. Thanks to that query, for example, allow us to define the number of retries as long as the delay between the retries. And if something fails after the retries, we can still visualize to the user what will happen if it fails. So always remember to visualize to the user what is happening.

We can specify for how long the stale time the data can become idle and then become updated. A third implication is that the connection handling, which is the HTTP call, the actual call that we make, becomes and should become resilient. There is a higher probability in this architecture for the HTTP call to fail because of network requests, because of the cold start that we mentioned earlier. That's why we have the option to retry the API calls. Thanks to that query, for example, allow us to define the number of retries as long as the delay between the retries. And if something fails after the retries, we can still visualize to the user what will happen if it fails. So always remember to visualize to the user what is happening.

These retries are suitable mostly only for GET calls, and we should avoid making retries on mutations. We saw earlier that we don't have now a bulk API route, but we have smaller serverless functions. That means that our frontend, our UI components are smaller and they are granularly talking to the respective serverless functions. Every component might fail or might be loaded at a different time, making loading states more granular in this architecture. Different loading states exist for a dashboard component or an item component. However, showing a spinner isn't always necessary as we have quick loading times below a threshold. We can specify when to show loaders, for example, only after the timeout passes, fetch updates silently, and keep the UI responsive.

Errors become critical in this architecture as any component can fail at any time. More frequent and unpredictable errors occur, leading to granular error handling not only at a root and feature level but also at the component level. Targeted fallback UI is used to isolate failures and maintain app usability. Custom error boundaries are specified in the code to show custom fallback UI per component instead of wrapping it on the whole app. Stay updated and learn through the newsletter for a new course on using data structures in the front-end through practical applications. Thank you all for your time.