Was ist Astro?

Astro ist ein Framework für contentfokussierte Webprojekte, wie z.B. Blogs, E-Commerce- oder Marketing-Websites. Es setzt auf eine komponentenbasierte Web-Architektur, was bedeutet, dass das meiste als statische HTML-Seite gerendert wird und man kleine Islands mit JavaScript für Interaktivität hinzufügen kann. Astro verfolgt einen Server-first-Ansatz und kommt standardmäßig ohne JavaScript am Client aus, liefert aber bei Bedarf Unterstützung für Frameworks wie React, Vue, Svelte, Solid etc. Darüber hinaus bietet Astro Content Collections, mit denen sich Markdown-Inhalte strukturiert organisieren und mithilfe von TypeScript typsicher validieren lassen.

Projekt erstellen

npm create astro@latest (basic, helpful starter Projekt auswählen)

In VS Code gibt es eine Extension namens Astro, die hilfreich ist.

Ordnerstruktur (als Beispiel):

• assets
• components
• content (für Content Collections)
• layouts
• pages (file-based Routing)
• styles

Dateiaufbau und Astro-Komponenten

• Dateiendung: .astro
• Codeausführung:
  • serverseitig: --- --- (Frontmatter)
  • clientseitig: <script></script>
• JSX-ähnliche Ausdrücke
  • {variable} in HTML
  • Aber: Funktionen und Objekte können so nicht übergeben werden (wie z.B. bei React), stattdessen mit Script-Tag umsetzbar

Beispielsweise MyAstroComp.astro:

---
// Script mit JS, das am Server ausgeführt wird
const text = "Hello World";
---
<!-- Hier Template der Komponente mit HTML, CSS und JS -->
<div>{text}</div>

Was nicht funktioniert:

---
function handleClick() {
  console.log("clicked");
}
---
<button onclick="handleClick()">{text}</button>

Komponente in index.astro verwenden:

---
import MyAstroComp from "../components/MyAstroComp.astro";
---
<MyAstroComp />

• <slot /> für Children (wie {children} in React)
• Mit Astro.props auf Properties zugreifen

---
interface Props {
  name: string;
}
const { name } = Astro.props;
---
<h2>Hello {name}!</h2>

Unterschiede Astro vs. JSX

React hinzufügen

Interaktivität in Astro Komponenten einzubauen ist mühsam. Um mit einem Buttonklick umgehen zu können, müsste man ein <script> Tag hinzufügen. Stattdessen kann man aber auch ein beliebiges anderes Framework zum Projekt hinzufügen und so auch beispielsweise React-Komponenten bauen und nutzen.

Um React als Beispiel hinzuzufügen: npx astro add react

Achtung: Komponente wird by default nur am Server gerendert!

Für Interaktivität braucht es Hydration und eine Client Directive.

Client Directives

Die client:* Directive gibt an, wann das JavaScript an den Browser geschickt werden soll. Die Komponente wird zuerst am Server gerendert (außer bei client:only), dann wird das JS gesendet und somit wird die Komponte hydrated und interaktiv.

• client: load
  • JS: sofort beim Laden der Seite
• client: idle
  • JS: nach initialem Ladeprozess und wenn requestIdleCallback-Event ausgelöst wird
• client: visible / client:visible={{rootMargin}}
  • JS: sobald Komponente bzw. angegebener Margin sichtbar ist
• client:media={string}
  • JS: wenn CSS media query erfüllt wird (z.B. nur für bestimmte Bildschirmgrößen)
• client:only={string}
  • Überspringt SSR und rendert Komponente nur am Client. Framework muss als String übergeben werden.

Die Client Directive wird dort hinzufügt, wo die Komponente verwendet wird.

---
import MyReactButton from "../components/MyReactButton";
---
<MyReactButton client:load />

Output Type für Build

In der astro.config Datei kann der Output Type festgelegt werden. Dieser bestimmt, wann die Seiten standardmäßig gerendert werden (beim Builden oder on demand). Das gilt für alle Seiten, außer bei denen eine Ausnahme festgelegt ist.

In astro.config.mjs: output: 'static' oder 'server'

• static (default): SSG, Seiten werden vorgerendert (prerendered); Ergebnis: statische Website
• server: SSR, Seiten werden on demand gerendert; Ergebnis: server-rendered Website
• Für einzelne Seite ändern: export const prerender = false
  • wenn in config static: false
  • wenn in config server: true

Wichtig: Wenn eine Seite SSR verwendet, muss ein Server-Adapter (z.B. node) festgelegt werden: npx astro add node

Blog als Praxisbeispiel

Als Beispiel wird ein kleiner, einfacher Blog programmiert. Dieser beinhaltet zwei Seiten, wobei auf einer alle Einträge mit Bild, Datum und Titel aufgelistet werden (Übersichtsseite) und auf der anderen die Informationen des jeweiligen Eintrags stehen (Detailseite). Die einzelnen Blogbeiträge sollen in Form von Markdown-Dateien erstellt, bearbeitet und verwaltet werden können. Auf das Styling wird bei diesem Beispiel nicht eingegangen.

Content Collection erstellen

Content Collections helfen dabei, Markdown-Dateien zu organisieren. Genau das wird für die Blogbeiträge benötigt. Um eine Collection zu erstellen, muss diese in src/content.config.ts definiert werden.

import { glob } from "astro/loaders";
import { defineCollection, z } from "astro:content";

const blog = defineCollection({
  loader: glob({ base: "./src/content/blog", pattern: "**/*.{md,mdx}" }),
  schema: () =>
    z.object({
      title: z.string(),
      date: z.coerce.date(),
      img: z.string(),
    }),
});

export const collections = { blog };

Die Funktion defineCollection() verlangt dabei zwei Parameter, einerseits den Loader und andererseits optional das Schema. Der Loader legt fest, wie und von wo die Inhalte der Collection geladen werden. Astro stellt dabei zwei integrierte Varianten zur Verfügung:

• glob(): erstellt Einträge aus Ordnern mit Dateien
• file(): erstellt Einträge basierend auf einer lokalen Datei (z.B. JSON-File)

Das Schema wird mit zod erstellt. Wird ein Schema definiert, so werden die entsprechenden Markdown-Dateien dahingehend validiert. Außerdem können generierte Types verwendet werden (z.B. type Props = CollectionEntry<"blog">["data"];). Wichtig ist nur, dass der Dev-Server neu gestartet wird, wenn sich Änderungen am Schema ergeben, sodass Astro das mitbekommt.

Ein Blogeintrag soll in diesem Fall immer einen Titel, ein Datum und ein Bild beinhalten, sodass diese Informationen auf der Übersichtsseite angezeigt und auf der Detailseite immer gleich formatiert werden können.

Blogbeiträge hinzufügen

Es können jetzt diverse Blogbeiträge in Form von Markdown-Dateien unter content/blog erstellt werden (Pfad in content.config.ts festgelegt).

Beispiel: first-entry.md

---
title: "First Entry"
date: "2025-10-30"
img: "/favicon.svg"
---
Hello, this is my first entry.

## H2

This is a paragraph.

Im Frontmatter (innerhalb der drei Bindestriche) werden die drei Parameter angegeben, darunter folgt der Inhalt. Als Bild wird der Einfachheit halber das favicon im public-Ordner hergenommen. Der Blogbeitrag kann Überschriften, Absätze, Links, Codeteile, Tabellen und alles, was Markdown zu bieten hat, beinhalten. Wichtig ist nur, dass man das entsprechende Styling dafür definiert (h2, p, code, a etc.).

MDX

Es können nicht nur md-Dateien erstellt werden, sondern auch mdx-Dateien, in denen die eigenen Komponenten (egal ob Astro, React etc.) verwendet werden können. Es muss nur die entsprechende Astro-Integration installiert werden (npx astro add mdx) und mdx in der Definition der Content Collection berücksichtigt werden (wurde bereits getan).

Beispiel: second-entry.mdx

---
title: "Second Entry"
date: "2025-10-31"
img: "/favicon.svg"
---

This is my second entry.

import MyReactButton from "../../components/MyReactButton"

<MyReactButton client:load />

components/MyReactButton.tsx

export default function MyReactButton(){

    function handleClick(){
        console.log("Hello, you clicked me")
    }

    return (
        <button onClick={handleClick}>Click me</button>
    )
}

Seiten erstellen

Astro verwendet file-based Routing. Die Ordner- und Dateistruktur im pages-Ordner bestimmt somit automatisch, unter welchen URLs die Seiten aufgerufen werden können. Im pages-Ordner wird ein Unterordner blog und darin index.astro und [slug].astro angelegt. Der Blog ist somit unter /blog erreichbar. index.astro ist eine statische Route, während [slug].astro eine dynamische Route ist. Der Parameter slug kann dabei durch eine beliebige andere Bezeichnung ersetzt werden. Für mehr Tiefe kann auch ein Rest-Parameter verwendet werden: […path].astro.

Übersichtsseite

Für die index Seite wird zuerst ein Layout erstellt. Ein Layout ist dabei nichts anderes als eine normale Astro-Komponente.

layouts/Layout.astro

---
import "../styles/global.css";
---

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="generator" content={Astro.generator} />
    <title>My Blog</title>
  </head>
  <body>
    <slot />
  </body>
</html>

<style>
  html,
  body {
    margin: 0;
    width: 100%;
    height: 100%;
  }
</style>

Für den Header kann ebenso eine Astro-Komponente erstellt werden (components/Header.tsx).

<header>
  <nav>
    <a href="/blog">My Blog</a>
  </nav>
</header>

Nun kann index.astro befüllt werden:

---
import { getCollection } from "astro:content";
import Header from "../../components/Header.astro";
import Layout from "../../layouts/Layout.astro";

const posts = (await getCollection("blog")).sort((a, b) => {
  return b.data.date.valueOf() - a.data.date.valueOf();
});
---

<Layout>
  <Header />
  <ul>
    {
      posts.map((post) => (
        <li>
          <a href={"/blog/" + post.id}>
            <div>
              <img src={post.data.img} />
            </div>
            <div>{post.data.title}</div>
            <div>{post.data.date.toLocaleDateString()}</div>
          </a>
        </li>
      ))
    }
  </ul>
</Layout>

Mithilfe von getCollection() kann eine Collection, sprich ein Array von Einträgen, geholt werden. In diesem Beispiel werden die Einträge von der Blog-Collection zusätzlich nach dem Datum sortiert.

Detailseite

Für die Detailseite wird ebenso ein Layout erstellt, das den Titel, das Bild und das Datum übergeben bekommt und anzeigt.

layouts/BlogLayout.astro

---
import type { CollectionEntry } from "astro:content";
import Header from "../components/Header.astro";

type Props = CollectionEntry<"blog">["data"];

const { title, date, img} = Astro.props;
---

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="generator" content={Astro.generator} />
    <title>My Blog</title>
  </head>
  <body>
    <Header />
    <main>
      <article>
        <div>
          <img src={img} />
        </div>
        <div>{date.toLocaleDateString()}</div>
        <h1>{title}</h1>
        <div>
          <slot />
        </div>
      </article>
    </main>
  </body>
</html>

<style>
  html,
  body {
    margin: 0;
    width: 100%;
    height: 100%;
  }
</style>

Die Detailseite muss nun den Parameter slug auslesen und die entsprechenden Informationen dem BlogLayout übergeben. Es gibt zwei Varianten, das zu tun, je nachdem ob man SSR oder SSG verwenden möchte.

Variante 1: SSR (on demand Rendering)

---
import { render } from "astro:content";
import { getEntry } from "astro:content";
import BlogLayout from "../../layouts/BlogLayout.astro";

export const prerender = false;
const { slug } = Astro.params;

if (!slug) {
  return Astro.rewrite("/404");
}

const entry = await getEntry("blog", slug);

if (!entry) {
  return Astro.rewrite("/404");
}

const { Content } = await render(entry);
---

<BlogLayout {...entry.data}>
  <Content />
</BlogLayout>

Mithilfe von Astro.params kann der Parameter slug ausgelesen werden. Mit getEntry() wird dann der entsprechende Eintrag geholt. Wenn es keinen passenden Eintrag gibt, wird 404 angezeigt. Um den Inhalt der Zielseite anzuzeigen, ohne die URL zu verändern, wird Astro.rewrite() genutzt.

Variante 2: SSG (statische Seite)

---
import type { GetStaticPaths } from "astro";
import { render } from "astro:content";
import BlogLayout from "../../layouts/BlogLayout.astro";
import { getCollection } from "astro:content";

export const getStaticPaths = (async () => {
  const entries = await getCollection("blog");

  return entries.map((entry) => ({
    params: { slug: entry.id },
    props: entry,
  }));
}) satisfies GetStaticPaths;

const entry = Astro.props;

const { Content } = await render(entry);
---

<BlogLayout {...entry.data}>
  <Content />
</BlogLayout>

Soll eine dynamische Route statisch sein, so muss sie eine Funktion namens getStaticPaths() exportieren, die ein Array an Objekten mit dem property params zurückgibt. So werden alle möglichen Paths vordefiniert. In diesem Beispiel holt man sich also alle Einträge der Blog-Collection in der getStaticPaths()-Funktion und über die Properties (Astro.props) können dann die Informationen des einzelnen Eintrags ausgelesen werden.

Fazit

Mit Astro können schnelle Websites erstellt werden. Wenn man bereits Erfahrung mit HTML, JSX oder React hat, so fällt einem der Einstieg in das Framework besonders leicht, da man viele vertraute Konzepte wiederfindet. Nur bei komplexeren Websites stößt Astro irgendwann auf seine Grenzen.

Quelle

https://docs.astro.build/en

The post Workshop | Astro appeared first on Mobile USTP MKL.

Idea

The goal of TreeFund is to provide an easy and transparent way for people to contribute to environmental restoration projects in St. Pölten. Its main focus is supporting tree planting initiatives and teaching new generations how to help our planet. The idea is to connect with individuals who want to make a difference and focus on their specific needs. People will first encounter TreeFund through posters and flyers placed around the city. A QR code on each will lead directly to the TreeFund website, where users can learn more, get involved, and track the impact of their contributions.

Implementation

As the first step in the implementation process, I created a user persona: Lisa Gruber, a student at the University of Applied Sciences St. Pölten.

Lisa is deeply environmentally conscious and eager to contribute to positive change. However, she often feels frustrated by the impersonal nature of many existing donation platforms. She wants to see the real impact of her actions and connect with initiatives that align with her values on a local level.

To personalize this process, the user (Lisa) first contacts TreeFund via a form describing their personal needs and where they want to see a part of the world a little greener. Only after the user is happy and the tree planting effort is accepted by the city, the payment process begins. 

To attract younger customers the design follows a minimalist aesthetic with clean whites and greens to emphasize the simplicity and positivity of the project’s goal. The design was first created in Figma with inspirations like Ecosia and TreeApp. My goal was to stick to a strict number of TailwindCSS colors. The website switches between Stone-50 and -100 for the background and Lime-400, -500, -600 and -800 for the green accents.

After the design process, the actual website was implemented using React, Next.js, Tailwind CSS, and Lucide for icons.

Link to the Web Application: https://fhstp-print2mobil.vercel.app/

Disclaimer: This is a personal project created for educational and illustrative purposes. It is not affiliated with any existing environmental organizations. The aim is to demonstrate how web technology can be used to promote sustainability and environmental awareness.

The post PrintToMobile | TreeFund appeared first on Mobile USTP MKL.

Idea

I tried to use the well-known store IKEA and its Catalog to implement my idea. This project aims to bridge the gap between physical catalogs and digital visualization. The core concept involves using QR codes placed on the product pages to link to an external web application. Once the user scans the code, this application can display a 3D model of the product above its corresponding picture in the physical catalog.

Implementation

For technologies, I used HTML, CSS and JavaScript. For the purpose of pattern recognition and tracking, I used the framework mindAR.js. For displaying the 3D Objects, I used the framework A-Frame. Sadly, the 3D objects that I used are very high fidelity and that impacts the performance of the application. So when you want to scan the furniture elements on the page, you have to be very careful, not to move too much or too quickly. It’s hosted on my own server as a docker instance using a Nginx web server.

Link to the Webapplication: https://.ikea-scanner.laschober.eu

Disclaimer: This project is not affiliated with, endorsed by, or in any way officially connected with IKEA. The use of IKEA’s name and catalog images is solely for illustrative purposes as a practical example for the proof of concept.

The post Print2Mobile | AR – Web Application to project 3D Objects onto a Catalog appeared first on Mobile USTP MKL.

We’ve all been there, standing in front of the fridge or in the supermarket aisle not knowing what to cook. Meanwhile, tons of perfectly good food end up in the trash every day.

Dishcovery not only inspires creativity in the kitchen — it makes sustainability simple, digital, and rewarding.

This project is not affiliated with BILLA or the REWE Group in any way. It is a purely academic student project, created for educational purposes only. No financial support, sponsorship, or compensation has been received from BILLA or any other company. Any use of names or logos is solely for demonstration purposes within the prototype.

iPhone design by Luis Orea
Icons designed by Kryston Schwarze https://coolicons.cool/
Illustrations/Icons designed by Freepick www.freepik.com

Other Projects

Swiva is a mobile app for saving ideas, places, recipes and activities from TikTok, Instagram, Maps and the web, and actually turning them into plans.

The post Print2Mobile | Dishcovery appeared first on Mobile USTP MKL.

In diesem Beitrag möchte ich den Aufbau der Anwendung, die verwendeten Technologien sowie einige Herausforderungen und Learnings während der Umsetzung vorstellen.

Technologie-Stack

Das Club Dashboard wurde als moderne Webanwendung mit Fokus auf Skalierbarkeit, Sicherheit und einfache Erweiterbarkeit entwickelt.
Hier ein Überblick über die zentralen Technologien:

Framework: Next.js (App Router)

Für das Frontend kam Next.js mit dem neuen App Router zum Einsatz. Diese Architektur erlaubt serverseitiges Rendering (SSR), API-Routen und eine saubere Trennung von Client- und Server-Komponenten. Dadurch konnte ich sowohl UI-Logik als auch Backend-Funktionalität innerhalb eines Frameworks umsetzen.

Vorteile:

• Serverseitiges Rendering für bessere Performance und SEO
• Integrierte API-Routen für serverseitige Logik (z. B. Payment Handling)
• Moderne Struktur durch den App Router

Data Layer: Convex

Anstatt einer klassischen REST- oder GraphQL-API habe ich mich für Convex entschieden – eine innovative Backend-as-a-Service-Lösung, die reaktive Datenabfragen, serverseitige Funktionen und Auth-Integration out of the box bietet.

Convex ermöglicht es, Daten- und Serverlogik in TypeScript zu schreiben und nahtlos mit dem Frontend zu verbinden. Dadurch entfällt ein Großteil der sonst notwendigen API- und Datenbankkonfiguration.

Styling & UI: TailwindCSS & shadcn

Für das Styling habe ich auf TailwindCSS gesetzt – ein Utility-First-CSS-Framework, das schnelles Prototyping und einheitliches Design ermöglicht.
Zusätzlich kam shadcn zum Einsatz, eine leichtgewichtige Component Library mit Fokus auf Barrierefreiheit, Dark Mode und Customizability.

Vorteile dieser Kombination:

• Konsistentes UI mit klarer Design-Sprache
• Wiederverwendbare Komponenten
• Effiziente Entwicklung durch Utility-Klassen
• Code Ownership: Components werden einfach ins Projekt kopiert

Authentifizierung: Clerk

Die Authentifizierung wird durch Clerk umgesetzt – denselben Anbieter, den ich bereits im ersten Semesterprojekt genutzt habe. Clerk bietet ein modernes User Management inklusive OAuth-Integration und JWT-Handling, was eine einfache Verbindung mit Convex und Next.js ermöglicht.

Durch Clerk konnte ich schnell eine sichere Login-, Logout- und Session-Logik aufsetzen, ohne selbst komplexe Authentifizierungssysteme implementieren zu müssen.

Payment Provider: Stripe

Ein zentrales Feature dieses Projekts war die Integration von Stripe als Payment Provider. Nutzer:innen können direkt über die Website eine Skiausfahrt buchen und bezahlen.
Dazu wurde das Stripe Checkout-System in die App eingebunden – inklusive Webhook-Handling, um Payment-Status-Änderungen serverseitig zu verarbeiten.

Beispielhafte Flows:

• User wählt eine Ausfahrt aus → Klick auf „Buchen“
• Stripe Checkout öffnet sich → Zahlung erfolgt
• Stripe sendet einen Webhook an das System → Buchung wird bestätigt und gespeichert

Diese End-to-End-Integration war der Kern des Projekts und erforderte ein gutes Zusammenspiel zwischen Frontend, Convex Backend und Stripe Webhooks.

Kommunikation & Webhooks

Ein spannender Teil des Projekts war die Kommunikation zwischen den verschiedenen Systemen.
Sowohl Stripe als auch Clerk arbeiten mit Webhooks, um Echtzeit-Informationen an das System zu senden (z. B. erfolgreiche Zahlungen oder neue Benutzer).
Die Webhooks werden über API-Routen in Next.js empfangen und anschließend in Convex weiterverarbeitet – beispielsweise um Buchungsdaten zu aktualisieren oder Rechnungen zu speichern.

Herausforderungen & Learnings

Während der Entwicklung gab es mehrere interessante Herausforderungen:

• Webhook-Handling: Das Zusammenspiel von Stripe, Clerk und Convex erfordert saubere Trennung von Sicherheits- und Logikschichten. Insbesondere das Validieren von Webhook-Signaturen war anfänglich fehleranfällig.
• Datenmodellierung in Convex: Da Convex ein eigenes Datenmodell nutzt, war es notwendig, sich in dessen Schema-System einzuarbeiten.
• SSR + Client-Komponenten: Der Wechsel zwischen Server- und Client-Komponenten im Next.js App Router war zunächst ungewohnt und erforderte ein gutes Verständnis des Rendering-Modells.

Trotz dieser Hürden war die Entwicklung äußerst lehrreich – vor allem im Hinblick auf Payment-Flows, Security und API-Kommunikation.

Fazit

Das Club Dashboard war ein spannendes Projekt, das mir erstmals die Umsetzung einer vollständigen End-to-End-Integration mit Stripe ermöglicht hat.
Durch den Einsatz moderner Tools wie Next.js, Convex, Clerk und Stripe konnte ich einen funktionalen MVP umsetzen, der reale Buchungsprozesse abbildet.

Besonders interessant war zu sehen, wie gut sich die verschiedenen Services über Webhooks und API-Routen integrieren lassen – und wie wichtig saubere Datenflüsse und Sicherheit in einem Payment-System sind.

Im nächsten Schritt plane ich, das Dashboard um weitere Funktionalitäten zu erweitern, um einem produktionsreifen Produkt näher zu kommen, das sich veröffentlichen und vertreiben lässt.

Screenshots

The post Projekt | Powda Club-Dashboard appeared first on Mobile USTP MKL.

Modularization

When you start a new Next or Nuxt application, you are tempted to throw all pages into the folder “pages” and all components into a folder “components,” etc. This will become a horrible mess once the application grows. My first and most important recommendation is to modularize the application ideally from the start. Each module holds its relevant code (pages, components, etc.).

It can be tricky to decide how to draw your modules. You can read the book “The Art of Micro Frontends” by Florian Rappl, which covers this topic in a chapter. The approach which has worked for me and my team was to first identify the domains of your application and make them modules. Later, you can split the code of the domains into further sub-modules representing individual features. With this clear structure, you will be able to navigate your code base easily and to see and enforce dependencies/relationships between the modules of your project.

You might want to convert some modules into micro-frontends, which are loaded at runtime. But be aware of the extra complexity which comes with micro-frontends. Again, I recommend reading the book “The Art of Micro Frontends” by Florian Rappl, which is a comprehensive guide in this regard.

SOLID

When designing software, keeping the SOLID principles in mind is essential. Yet, it seems that there is only little awareness of this among web developers. For creating the architecture of your project, I want to especially highlight two principles.

Open/Closed Principle -> software entities should be open for extension but closed for modifications.
Dependency Inversion Principle -> depend upon abstractions, not concretes.

They will lead to a special approach when designing your code. Let me give you an example. In an e-commerce application, you might have a module holding the code for displaying a product and another module which holds an add-to-cart button. Now, according to the principles, you would create your product view to contain and expose a slot which receives the product data. The module containing the add-to-cart button registers the button inside the product view’s slot. The result is that the module with the product view is extended without having to have knowledge of the add-to-cart button.

Feature flags

You modularized your application, and the code which belongs to the individual domains and features is in the respective location. You might have noticed that this structure encourages using feature flags to enable/disable modules. Feature flags might be necessary because your application is supposed to be distributed in different configurations. But feature flags have another interesting and powerful use: releasing features by activating a feature flag instead of by deploying your application. The idea is, when you are ready to release a feature, you deploy the application without the feature being activated. For more detailed information on the benefits and additional use cases of feature flags, please read the article “Feature Toggles (aka Feature Flags)“ by Pete Hodgson (https://martinfowler.com/articles/feature-toggles.html).

What’s next

I hope this article gave you good ideas on how to design your application. I am looking forward to comments and discussion as this is a very relevant topic to me. This article might require follow-ups which are dedicated to specific technical implementations of the described principles.

The post Architecture of large frontend applications appeared first on Mobile USTP MKL.

This tool makes it easy to convert photos of your recipes into a machine-readable format.

The output format is a subset of the schema.org Recipe and can be expanded (merge request are welcome).

How it works

The Recipe Scanner is a web application built with the Nuxt framework. Through its user interface, you can upload photos of recipes, which are stored on the server. The server then sends the images, along with a prompt, to a vision Large Language Model (LLM). The LLM extracts the relevant recipe information and formats it as specified. Finally, the server validates the structure of the returned data and sends it back to the client.

Technical considerations

This application was created for personal use (I wanted to digitize many old and messy recipes from my school days) and for experimentation so it is not designed to be fully “production-ready.” This influenced some of my technical choices.

For instance, I wanted to try out running a vision LLM on my own machine instead of using a hosted service. I tried out Ollama and LM Studio and opted for the latter because its interface made managing connections easier. In principle, Ollama should also work.

I also tried out several models. I began with the smalles vision-enabled Gemma 3 model (4B parameters, 3.3 GB). Unfortunately, it made many errors when extracting recipe data. Hosted models such as ChatGPT-5 and Mistral (Large?) performed much better, proving the task was feasible for LLMs. Among open-weight models, Mistral Small 3.2 (24B parameters, 15 GB) was the first that consistently produced accurate results. It’s possible that bigger Gemma 3 models (e.g., 12B) or specialized models like LLaVA, could also perform well or even better. If you test them, I’d be interested in hearing your results.

Another unusual design choice is how persistence is handled. Since this is a personal project, I opted for simplicity. The server does not use a database. There are no user accounts and images and parsed recipe data are saved directly to the server’s file system. To simulate a multi-user experience, each user only sees their own recipes. This is managed on the client side by storing image IDs in the browser’s IndexedDB. IndexedDB is not the ideal tool for this, but I wanted to experiment with it.

Next steps

My immediate goal is to digitize my collection of printed and handwritten recipes. Once that data is gathered, I plan to use both the images and extracted recipe information to fine-tune a smaller, more efficient model specifically optimized for this task.

Link to the repository: https://github.com/realJanWeiss/recipe-scanner

The post Projekt | Recipe Scanner appeared first on Mobile USTP MKL.