Stex

Key Features

Tech Stack

• Java
• Spring Boot
• React.js
• Docker
• PostgreSQL
• Resilience4j
• Postman
• Swagger
• GitHub Actions
• Caffeine Cache

Why I built Stex

Stex was actually the first idea I ever had for a project - but like most “one day I’ll build this” ideas, it gathered a bit of digital dust before I finally gave it a shot (read: a year). The idea came from pure frustration, SL used to show which subway door would put you closest to the exit, and then... they just stopped. I missed it every time I found myself sprinting down a platform. So, I thought, why not build it myself? I knew the logic would be quite complex, and I wasn’t even sure it was fully possible, considering API limitations and costs. The frontend wasn’t the main focus either, so I decided on a single-page without too much fluff. It's built in React.js, mainly because I wanted to try it out.

The process

Before I wrote a single line of code, I did a lot of research. The first question was whether this project was even feasible without turning into a paid side project. I looked into different APIs to see what was available for free, what kind of data I could actually access, and what I would need to make the logic work.

Once I knew it was possible, I started planning properly. I created a backlog, user flows, and the diagrams I needed to understand both the problem and the solution. From the start, I knew I wanted to host the application somewhere so my friends could actually use it, which meant researching free (or at least cheap) options for frontend, backend and database. With that in mind, I sketched out the overall structure, what components I needed, how the logic would work, how data would flow through the system, and how everything would fit together. I also had a rough idea of how I wanted the design to look - simple, clean and focused on functionality rather than visuals.

Problems

Where do I even begin? Initially, fetching a station and all its entrances resulted in excessive database queries. I solved this by implementing JOIN FETCH in JPQL to retrieve all related data in a single optimized query. Relying on external APIs (SL/Trafiklab) meant the app could crash if they went down. I implemented the Circuit Breaker pattern using Resilience4j. Now, if the external service fails, the app degrades gracefully or serves cached data instead of hanging.

Lessons learned

• Start small, dream big: This project reminded me that even simple ideas can hide surprisingly complex logic under the hood.Breaking the problem down into manageable steps kept me from getting overwhelmed early on. It’s okay to start without all the answers. I didn’t know if this project was even possible at first, but breaking it down step by step made it manageable.


• APIs are not magic spells: Just because an API exists doesn’t mean it gives you what you need, or in the way you want it. Learning how to work with incomplete data, and combine multiple data sources, was a big part of the challenge.


• Logic is the real final boss: Most of the complexity in Stex wasn’t writing code, but figuring out how the problem should be solved.