Lexora

Problem

Most library systems are either clunky desktop software or expensive third-party platforms that don't fit smaller libraries. I wanted to build something lightweight and self-contained — a backend that enforces borrowing rules reliably, and a frontend that feels natural for both everyday borrowers and the staff managing the shelves. The tricky part was the rules: return deadlines, outstanding fines, borrowing limits, and user restrictions that all stack on top of each other.

Approach

I separated concerns from the start: business logic (penalties, restrictions) lives in a dedicated service layer isolated from the controllers, so it can be tested independently and changed without touching the API surface. ASP Identity handled role management so I didn't have to reinvent it. On the frontend, I chose Razor Pages to keep the server-rendering close to the data layer — tying the UI tightly to the API's data contracts meant the two could evolve together without drift, and Swagger became the primary reference during frontend development.

What I learned

• Separating business rules into a service layer pays off quickly — the borrowing logic changed several times, and isolated services made that painless.
• Razor Pages works best when the UI maps closely to server-side actions — fighting that model adds unnecessary complexity.
• JWT handling in a server-rendered context requires careful cookie/header strategy to avoid leaking tokens in the DOM.
• EF Core migrations are only as good as your discipline around naming and staging them — undocumented migrations are a future maintenance headache.
• Swagger is a first-class development tool, not just documentation — writing it upfront sped up frontend integration considerably.
• PostgreSQL's row-level constraints caught data bugs that application-level validation would have missed.
• Designing for two distinct user roles (borrower vs. admin) from the start saves a lot of retrofitting later.