Architecture
This page explains the most important aspects of the architecture. To read more about the decisions and the principles behind them, see Chapter 4.
Chips and Code is primarily a client-side web application. This decision was made for two reasons:
- Connectivity: To make sure the application does not depend on an internet connection and is available with poor or even no connectivity. This also means the design should not be disadvantaged in this regard compared to a desktop application.
- Reproducibility: No dependence on the cloud means it should be much easier to deploy to any (free) CDN, any simple web hosting, or even run locally or bundled as an Electron — desktop — or a Capacitor — mobile — application.
To double down on this approach, it is also a Progressive Web Application (PWA), which means it can be installed on any combination of a major internet browser and OS. Thanks to a service worker that is configured to cache all assets as soon as the user visits the website, all functionality should be available at any point, even once the user loses the connection.
To enable the static file approach, the whole application has to be built ahead of time during the building phase instead of relying on Server-Side Rendering (SSR).
Although Sveltekit used for this project defaults to platform-specific SSR, it is possible to configure it to generate static assets and work as a Single Page Application (SPA) for pages that are not completely static.
In this case, the resulting bundle of static files is deployed via Cloudflare Pages, but there are many equivalent services that can easily host static assets for free.
For a proper CD implementation, the build is triggered on push to Repository, and every branch is deployed as branch.chipsandcode.pages.dev. The main branch is mapped to the primary domain name chipsandcode.com.
Optionally, it is possible to persist files to the cloud—in this case, a simple custom-made Representational State Transfer (REST) API written as a serverless application running on Cloudflare Workers. The API is consciously kept separate from the client-side application, although it does re-use code where it makes sense, e.g., validation schemas.
The same branch-level deployment applies to the server-side code. However, one limitation is the storage is not separated for each branch. Rather, there are only two key-value namespaces for production and development, with the latter used for branch previews as well. Even though the cloud functionality is optional, it was still kept to a minimum (it is only about 200 lines of code) so that it is easily replaceable. Additionally, local development does not depend on Cloudflare as it uses a simulated local environment with a SQLite database.
All in all, while Cloudflare deployment is mentioned in the supplied README, anybody who wants to contribute or adapt the project does not need to worry about it if they do not want to. The cloud functionality is opt-in even for developers and can be enabled by setting a single .env variable.