The most important programming-style and architectural decisions I make as a frontend (or full-stack) developer building a complex application:

• TypeScript types are the glue that holds the application together and ensure changes can be made quickly later when you revisit older code. Server-client communication is secured with end-to-end type-safety (also a classic source of bugs in applications — the API changes but you forget to update the dependent clients).

• Domain-driven design is the architectural foundation for any complex application, as it ensures related functionality lives together and is not spread across distant and overcrowded folders. Concretely this means a subfolder in src/modules/ (or whatever you prefer) that contains everything related to users, subscriptions, posts, and so on. Each module is built as follows:

I used to host the web app (SQLAI.ai) on Vercel and still do, but I moved the “app” portion to Cloudflare, given the much broader feature set and significantly lower price. The app is deployed on a subdomain and runs completely separately. I initially wanted to move the landing pages to Cloudflare and port them to Astro, but it was too much work moving all the legacy pages for too little value. Naturally, I wanted to downgrade from Vercel Pro to Hobby, since I didn’t think I needed any Pro features and $20 is expensive. For comparison, I pay $5 for Cloudflare’s Paid Worker and another $5 for database hosting on Railway. Vercel charges four times that.

Partytown is a library dedicated to offloading third-party libraries such as tracking scripts to a web worker, i.e. downloading and executing them in the background. Partytown is easy to install but is still in beta and the documentation is a little lacking. To make Partytown and Google Analytics work as expected in relation to Google Analytics’ official documentation, two changes are necessary. Here’s how to install Partytown and Google Analytics in an Astro web app:

The main advantage of server-side applications is that you can render large parts of applications on the server, where there is already access to the database and other configurations that do not exist on the user side without building an API logic. But one of the most important elements for usability is that the application loads quickly. Server-side rendered applications of course have an advantage in that you can send less code to the user; an example is a header that either contains a login button or a user panel. The server-side rendered application would only need to send either a login button or a user panel because it can check on the server if the user is logged in.

If you want to use Gemini’s public API, but at the same time have a safe fallback in case you have exhausted the rate limits, you can use the OpenAI TS/JS library and a few helper functions. In my particular case I needed a type-safe solution for a chartmaker app with a fallback since Gemini’s gemini-2.5-pro-exp-03-25 model is restricted to 20 request/min.

First, you need to define which models you want to use so that they appear as autosuggest when you use the helper functions: