ApexFlow

Context

For my Computer Engineering thesis I wanted a project with real problems to solve. ApexFlow simulates a SaaS platform that a tech company would use to manage customers, subscriptions, products and orders, with the constraints of a production system.

How it is built

• Angular 19 single-page app with standalone components and Signals for state.
• PrimeNG for data-heavy components: tables, forms, dialogs and toasts.
• Role-based access with route guards (admin-only settings, profile pages limited to the owner or an admin).
• HTTP interceptors that attach the bearer token and turn API errors into toast notifications in one place.
• Spring Boot 3 REST API on Java 21 with Spring Data JPA, PostgreSQL and Docker; frontend on Vercel, backend on Render.

Key decisions

Signals for state, RxJS where time matters

Authentication state lives in signals, so the components never subscribe or unsubscribe by hand. RxJS stays where it is the right tool: debouncing filters and cancelling stale requests.

Server-side tables with one reusable state class

A TablePaginationState class keeps page, sort and filters in the URL and bridges signals and observables with toSignal and toObservable. Changing a filter or a page triggers exactly one API call, and every table in the app reuses the same logic.

Spring Boot instead of a JavaScript backend

NestJS would have kept everything in TypeScript, but Spring Boot is what most of the job posts I read asked for next to Angular. With two languages, the contract between client and server has to be explicit: every field the frontend relies on is a decision.

Outcome

I graduated in April 2026 with ApexFlow as my thesis. The live demo has one-click demo accounts for an admin and a regular user.

I wrote about it

• Ten records is easy, ten thousand is engineering
• Signals in a real app: the ApexFlow auth module
• Why Spring Boot when I already knew TypeScript?