V2 lives in a new repository, but it is of course built on Version one. The tracker is still at its core and around it, OnTime now handles teams, invoices and payments.

What changed

In V1, one person tracked their own time but in V2, everything happens inside workspaces. A workspace can consist of just you or a whole team and every member has one of four roles: owner, admin, manager or member.

But the basics are of course still there: a timer, manual entries and clients, projects and tasks with their own detail pages. The calendar is now shared and even updates live across devices. Projects can have budgets that send a notification when they cross a threshold. The whole app is in English and German and on mobile it works offline thanks to a persisted query cache.

Invoices and payments

This is where V2 changes the most from its previous version. Billable time becomes an invoice and when you send it, an Edge Function renders it as a PDF and freezes it. If you edit the underlying time entries later, the document the client already received doesn’t change.

Additionally, OnTime connects to your bank through Enable Banking. The connection is read-only by design and you bring your own credentials, which are stored encrypted in Supabase Vault. A scheduled pg_cron job pulls in transactions and matches them against open invoices. When a match is confident, the invoice is marked paid automatically. Everything else waits in a queue for one-click review.

Database changes

V1’s database only had to serve one person tracking their own hours. V2 needed a real data model, so I didn’t patch the old schema and started from the start.

As said before, Everything belongs to a workspace: Clients, projects, tasks, time entries and invoices all hang off a workspace and every row knows which workspace it belongs to. That one change is what makes teams possible. It’s also what the security model is built on.

Also, every table has row-level security policies that check the caller’s workspace and role before returning a single row. Views run with security_invoker, so they apply the permissions of the person querying them instead of quietly bypassing them. Owners, admins, managers and members all hit the same tables and get different answers. Since the frontend isn’t trusted to enforce any of this, pgTAP suites test the rules against a real database.

Another security measure was to add a timestamp to entries when they get deleted. Now they are moved to a trash view, where they can be restored. A pg_cron job purges them for good once they’ve been in the trash long enough, so nobody has to clean up by hand.

An invoice can’t point at time entries and hourly rates, because those can change or be edited. When an invoice is sent, it stores a JSONB snapshot of everything it was built from and the PDF is frozen alongside it. Rates also keep a history, so billing a project in March uses March’s rate even if it went up in June. Invoice numbers are generated per workspace and restart each year.

pg_cron also triggers the bank sync so that transactions come in on a schedule, get matched against open invoices and confident matches mark the invoice as paid. The bank credentials never sit in a plain column and are encrypted in Supabase Vault.

The shared calendar and the notifications subscribe to database changes through Supabase Realtime. When someone stops a timer on their phone, the entry shows up on everyone else’s desktop without a refresh.

Testing

Tests run in three layers:

• Vitest for units and components
• Playwright end-to-end tests against a preview build
• pgTAP for the security rules

Unit and end-to-end coverage are combined into one number and uploaded to Codecov on every CI run. Right now I have about 40% coverage but that will still be improved in later versions.

The post OnTime V2 appeared first on Mobile USTP MKL.

Rev Match Market is a used car marketplace lead by the left right swiping mechanism for marking interest in used car postings and connecting buyers with sellers. This blog post describes the second phase of development that took place on this project. Initially a MVP was made in the 1st phase that already contained the following features: authenticated sessions, swipe-based discovery, favorites, and seller listing management. For further reading about the 1st phase find the previous blog post here.

As a continuation to the initial MVP, the 2nd phase’s main goal was to introduce buyer-seller communication within the application aided with a notification system informing buyers and sellers about new interactions from each other. Another goal was to significantly improve the mobile experience and expand the capability of the UI from a single mobile view to a responsively transitioning UI that supports desktop, tablet, and mobile. Additional goals were the implementation of a concrete sold state that could later be the starting point of KPI tracking. Finally, to be able to later experiment with the app as a real business the application structure and code quality was to be made more production-ready.

2. From Phase 1 MVP to Phase 2 – The Plan

The starting point of the 2nd phase was directly from where phase 1 and the last blog post left off.

• Authenticated marketplace.
• Seller listing creation, editing and soft deletion.
• Swipe-based discovery with LIKE and PASS.
• Favorites and basic make/model/price filtering.
• Nuxt, NestJS, PostgreSQL and Prisma foundation.

The features implemented by phase 2 in order of priority.

• Mobile-first redesign before implementing major new screens.
• Chat and in-app notifications as the main new product features.
• Improved marketplace filtering and incremental feed loading.
• Cleaner domain boundaries, response contracts and privacy handling.

The result speak for them self, even if at this point of the blog only visually.

3. The Mobile-First Interface

Shared Application Shell
The shell places the screens in a wrapping element which provides consistent navigation throughout the navigation between pages and also provides a responsive layout. The components and visual primitives used in the application are also standardized across the different pages including spacing, typography and interaction states. This meant that many components from phase 1 have been completely replaced with special care so no parallel or redundant designs would have to be maintained.

Screen Changes and Account Identity
To start off at the beginning of users journey the login and registration pages have been completely redesigned and made responsive, along with the swipe, car-detail, favorites and seller-listing screens. A visible addition to the users was also made by displaying a name for user facing identity. The user identity also gained increased protection, since emails and user IDs of other users are no longer reaching the frontend other than public contact information on car-detail pages.

4. Improving Marketplace Discovery

A task originally coming from phase 1 has been implemented and improved, which is pagination and filtering of the queue of cars on the swipe page. First of all Filtering did already exist but it is now moved from the frontend to the backend. The number of filters remains small though now its way easier to expand. The front end now only holds a limited number of cars that come next and before the queue is exhausted the prefetching of new cars occurs. Pass decisions still expire and listings return to the queue later.

5. Communication (Chat), Notifications and Sale Lifecycle

This section is arguably the most important for phase 2. This encapsulates Likes creating conversations, the chat experience between buyer and seller, in-app notifications, and a new state for listings “SOLD”.

LIKEs and conversations
As one can know from phase 1 when a user likes a listing, the listing appears in the users favorites tab. Now following that the seller also receives a notification of a potential buyer who liked their listing. To avoid the creation of empty conversations a like in it self doesn’t create a new conversation. Following the like both parties get the chance to initiate a conversation. The seller can initiate from the notification they receive and the buyer can start a chat from the favorites tab or the car-detail page. Either way a new conversation is created when the first message is sent. There can only be one conversation per car and interested buyer.

Chat experience
Chats appear in a list like page which provides basic information to the user about all the chats like total number of unread messages and about individual list items representing a single chat like the last message, the time it was sent and the car that is the subject of the conversation. Chats can still be reached following a successful sale or if a buyer decided to withdraw interest. When a listing is deleted the chat is still readable but new messages are blocked.

In-app Notifications
The two sources of notifications are the Likes and messages. When the application is open and the user receives a notification an in-app popup appears temporarily. In case the user misses the popup, they might still access the notifications in their inbox with a list view. The notification inbox list view similarly to the chat shows notification contents, read or unread states and a counter for all unread notifications. The user can mark only one notification or all at the same time as read.

Sold Listing
The listings can be marked as sold only by the seller. They can do this either from the listing itself or the conversation which will associate the conversation with the successful sale. Sold listings can’t be found on the swipe page anymore and buyers may no longer start new conversations about the sold listings. Within favorites or existing conversations, the listing shows up as sold.

6. Technical Foundation and Data Model

• RevMatchMarket still uses Nuxt 4 for the frontend, NestJS for the backend, and PostgreSQL with Prisma ORM for the database.
• New persistence models that were added in phase 2 are conversations, messages, notifications, and sold state.
• A major change is the increased privacy meaning that response DTOs no longer expose account email and userID.
• The development process was also improved between phases 1 and 2 by using dedicated git feature branches merged into develop and later charry picking from develop to main (production).

7. Challenges and Lessons Learned

The first challenge was to plan the chat and notification system before implementation, what I learned is that it is significantly easier if the process is visualized beforehand using one of many flow chat methods. I also learned about the effort required to produce production grade code, where edge cases have to be treated with special care. I have learnt about several new techniques listed below.

Cursor Pagination
Pagination is used when requesting batches of a long list of data from the API. Cursor pagination loads the next group of records relative to the last record already received. This differs from the more simple offset pagination which requests by skipping x amount of records from the start. A cursor marks the last record loaded by a deterministic value in most cases a timestamp and the record’s id. This is used on RevMatchMarket’s swipe feed, and notification and chat inbox for example to avoid duplicate or skipped records.

Client-side Reconciliation
Reconciliation is to be understood as checking back with the API new data based on the data the browser already had. This process merges new server data with the existing state of the browser. This technique is important mainly because the application uses polling to fetch new messages or notifications. In case a notification is deleted and at the same time the polling occurs the deleted notification may appear again because the polling happened before the delete went through. When new server data arrives it is merged with the browser data by comparing IDs and the newer updatedAt wins over the older one.

Prefetching
The swipe page uses prefetching to achieve a continues feed. When only 3 cars remain from the previous batch of 20 a newer batch is fetched. To have a fluid swipe feed additional steps are also taken to filter out duplicates, potentially successful swipes can’t be re-introduced again, and account and filter changes are watched.

8. Results

The development in the 2nd phase yielded the following results: a completely reworked design and application structure, the ability for buyers and sellers to connect within the application after a potential buyer liked a listing, a notification system to keep buyers and sellers up to date with liked and owned listings, and finally a revised discovery logic that is more reliable and scalable.

The post RevMatchMarket Phase 2 – From Swipe-Based Browsing to Buyer-Seller Communication appeared first on Mobile USTP MKL.

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.