KallaX.io - A Web App?

This post explains in layman's terms how KallaX works. This post is meant for non-technical people - hence some technical concepts are oversimplified. If you understand the term 'hosted Blazor WebAssembly application' then this post is probably not for you. Some technical concepts are oversimplified.

This blog functions as a Traditional Website.
Your browser requests the content of /kallax-io-a-web-app from a server, in this case a server located in Amsterdam Paris and hosted by DigitalOcean Scaleway.

The server then works its magic and responds with exactly what your browser needs to render this specific page. This process is repeated when you click on another link, like /slug-generation. Your browser has no idea how to render this page and send a request all the way to Amsterdam Paris and wait for my little server to respond before showing you the next article. If you lose internet connection, you lose access.

I am using a CDN (Content Delivery Network) so your browser actually requests a cached version from a CloudFlare Bunny edge-server close to you, but that is beside the point...

Your phone is running applications!
Your phone is running fully-fledged applications. You can play Subway Surfers and most other games with or without an internet connection because your device already has everything it needs to run installed locally.

Some features might not be available to you offline, but the application works and can tell you this in a user-friendly fashion. The Messenger app works without a working internet connection but gets a bit boring after some time... Freemium games can't serve you ads if you don't have an internet connection when you launch the application - but the application works perfectly fine. wink, wink.

KallaX.io is a mix...
You might notice that KallaX.io is noticeably slower than other websites when you visit the site for the first time. Your browser requests /index.html and the server responds with a somewhat ugly loading screen - while the application downloads and installs in the background. You can think of this as downloading the entire website instead of just a single page.

However, serving subsequent pages is a lot faster because the browser already knows how to render the page. No need to ask a server far away and wait for the response. Going to the search page will therefore quickly show you the search component in a loading state. Your device already knows how the search component should look as it is part of the application - but does not have any games stored locally to show you. The first search, therefore, takes some time as your game collection has to be downloaded from the server but subsequent searches are served almost instantaneously. This is because everything runs locally on your device. The server is never even contacted and you can turn off your internet connection without affecting the search functionality (until you request a collection that is not yet cached on your device).

This approach gives several benefits and a few headaches.

👋 Network delays
The local application can render parts of the page without contacting the server - and sometimes the entire page if the data is already cached. This gives a greater perceived performance - or in human words - a more responsive website.

Less Work for the ☁️
Your application does most of the work and only contacts the server when it absolutely needs to. This means less work for the server, which means I can get away with running a smaller instance - which means I pay less.

Works Offline 🌏 - ish...
The application can theoretically work offline. This has not been a priority to me - so data is not cached between sessions. This means an internet connection is required to start the application - but this approach still provides great benefits to people with spotty or slow internet connections.

... but, there are also some caveats.

🐌 First rendering is slow
Rendering the first page is slow. This could be alleviated with pre-rendering; a concept where the server renders the first page (like a traditional website) for you and then lets the app take over to render subsequent requests. The page would not be functional until the app started up but it would look correct.

This also greatly affects how well Google likes us (they do not...)

Security 🔒
The code for the entire application is running on your device. This means you can take a look and peep around - provided you have the required technical skills. There are no secrets in the source code, but it's worth keeping in mind when jumping from developing traditional websites to web apps.

Multiple versions✨
Running a traditional website is nice. Everyone is always using the newest version - because there is only one truth, your server. This is not the case with web applications. Clients can have old versions lying around in their caches and you have to keep this in mind when updating your APIs.

What is KallaX?

Ohh. It's a small project I am working on. A web application for managing your board game collection - if you have one. You can read about it here 👇

[PROJECT KALLAX]

or jump directly to joining the conversation on Discord