A Virtual Frontend Buddy

Published in

Product & Engineering at Showpad

5 min readFeb 11, 2022

Although this isn’t a story about imaginary friends, I’d like to imagine a friendship between a real version of “X” and a virtual version of “X”, the latter being a helper or buddy to the former, working together in a beautiful symbiosis. “X”, in this case, is your application’s frontend.

Come again? A virtual frontend? Well, yes, one that does the heavy lifting for the real frontend, in the background, in a safe, reliable and fast environment, one that you can control.

The idea is simple. The implementation may be trickier. But, I do believe the current state of Cloud computing allows for this concept.

The concept

A user navigates to your application and finds an athlete working their way over the finish line in slow motion... (slightly drop the pitch of your inner voice as you read this). You know it’s an athlete, you’ve been training it for years to be as performant as possible. Still, to the user, it’s perceived as slow motion...

What can you do to speed things up?

reduce the number of network calls
prefetch assets
make the server respond faster
minimise the code
inline any styles and scripts needed for the first paint
lazy load anything that’s not needed right away
optimise images
add a service worker for caching
set up server side rendering
talk to your marketing friends to get rid of their tracking scripts 🙈
…

You see, there’s lots you can and should do. However, I’d like to focus on one of these: “Make the server respond faster”. You can do this by adding a caching layer to your API and your database or by diving into the code to see what other performance improvements are possible. Ultimately, you’ll hit a limit and you’ll have created the fastest possible solution, a beast, even faster than your previous champion!

Still, depending on the complexity you may need to run complicated queries on your database or generate complex content. Maybe those take seconds to resolve or create. Seconds, to the end user, will still feel like slow motion…

What if you could spin up a frontend, an exact copy of the user’s frontend, that lives server-side. Each browser session would have its own virtual frontend in the cloud. An exact copy, but with some extras. Say, for example, that it would pretend to be the user and starts opening every page available, or following predefined scenarios, while the real user on the other hand is currently reading a paragraph on their landing page. This would prefetch more data than a regular prefetch would when it’s initiated in the user’s frontend. Also, you could bypass the login screen, depending on the situation, after all, we’re working on the trusted server (but don’t forget to require authentication to anything you serve to the user). What if you could pre-cache all these requests and serve them to the user instead of letting the user request them on demand while browsing?

Imagine every page and asset being preloaded, in-memory on the server.

You could use the HTML as a source for server side rendering solutions.
You could use the server requests as cache.
You could mimic the user’s screen resolution and serve the images in the best possible format.
You could bypass the login screen and start prefetching things you couldn’t prefetch while tackling the frontend performance improvements mentioned before (be aware of security pitfalls though!).
You could preserve this state to have it available the next time the same user comes by (take into account legislation about sensitive data and data retention!).
To some extend you could even pre-generate personalised or time sensitive content (if the time window allows for some delay). This would be impossible with any other caching layer.

Example of a possible implementation using AWS services

Existing solutions

Currently you can find some similar tools on the market. They mainly focus on page speed, pre-caching and SEO. Their techniques include static site generation, server side rendering and incremental static regeneration. The latter comes pretty close to our “Buddy” concept. But, the key differentiator is dynamic content, tailored to the user’s needs. None of these solutions have a real answer to how to pre-cache personalised or other highly dynamic content. By autonomously browsing a copy of the user’s frontend, our “Buddy” concept can provide pre-caches in these situations.

Caveats

You must keep in mind that a virtual frontend will generate real traffic. The backend should be aware where this traffic originated. The frontend should also be aware it’s running in “virtual” mode. Think about adding specialised parameters to all requests (query string parameters, custom headers,…). That way you can keep your statistics and logs clean. These parameters could also serve as a way to deprioritise this traffic. The “Buddies” shouldn’t get in the way of the real users.

Conclusion

Don’t expect a detailed walk-through tutorial on how to implement this “Virtual Frontend Buddy” of ours (maybe one day, who knows…). For now, this is all still theory and just a concept I was thinking about. I’m curious to see and hear what you think about it and if you can come up with nice implementations if you decide to give it a try.

Your application could benefit from it, but on the other hand, it may use too much resources and prove to be too expensive. I guess a lot depends on the cloud solution, their offering and your implementation.

Have you tried something similar before? Feel free to share your thoughts in the comments section below.

Interesting links:

Want to join our team and help us build awesome things?
Visit our careers page.