DEV Community: Marcin Parśniak

From Email to User ID: A Security-Driven Refactor in Spring Boot Backend - Finovara

Marcin Parśniak — Sat, 18 Apr 2026 09:26:52 +0000

At some point, a backend outgrows its initial assumptions.

In my case, that assumption was simple:
email = user identity

It worked fine early on. It was convenient, readable, and easy to query. But over time, it started to create real limitations—both in terms of features and security.

This post is about why I moved away from using email as the primary identifier, what had to change, and what improved as a result.

The Problem with Using Email as Identity

Initially, email was used everywhere:

in JWT subject
in database queries
across service layer logic

Typical example:

userRepository.findByEmail(email)

And in JWT:

.setSubject(user.getEmail())

This approach has one fundamental flaw:

Email is not a stable identifier.

The moment you want to support changing email, things start to break:

JWT tokens become inconsistent
existing sessions may become invalid
references across the system lose integrity

In practice, it blocks you from implementing a very basic feature: updating user email.

Why This Matters

Using a mutable field as identity introduces a few issues:

1. Tight coupling
Your entire system depends on a value that can change.

2. Inconsistent authentication
JWT subject no longer represents a stable user reference.

3. Limited extensibility
Features like:

email change
social login
account linking become harder to implement cleanly

The Refactor: Switching to User ID

The core idea was straightforward:

Use userId as the single source of identity across the system.

Email is now just a property of the user—not something the system relies on for identification.

Key Changes

1. JWT now stores user ID

.setSubject(user.getId().toString())
.claim("userId", user.getId())

This ensures:

the identifier is stable
it maps directly to the database
it doesn’t change over time

2. Extracting user ID from token

public Long extractUserId(String token) {
    Claims claims = extractAllClaims(token);

    Object userIdClaim = claims.get("userId");
    if (userIdClaim instanceof Number number) {
        return number.longValue();
    }
    if (userIdClaim instanceof String userIdText) {
        return Long.parseLong(userIdText);
    }

    return Long.parseLong(claims.getSubject());
}

This handles multiple formats and keeps backward compatibility with older tokens.

3. Authentication filter now works with ID

Before:

findByEmail(...)

After:

Long userId = jwtService.extractUserId(jwt);
User user = userRepository.findById(userId).orElse(null);

This removes ambiguity and avoids relying on user-controlled fields.

4. CustomUserDetails updated

private final Long id;
private final String email;

The important part is that ID is now always available in the security context.

5. Centralized access via SecurityUtils

public static Long getCurrentUserId() {
    Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

    if (authentication == null || !authentication.isAuthenticated()) {
        throw new IllegalStateException("No authenticated user in security context");
    }

    Object principal = authentication.getPrincipal();

    if (principal instanceof CustomUserDetails userDetails) {
        return userDetails.getId();
    }

    if (principal instanceof String principalValue) {
        return Long.parseLong(principalValue);
    }

    throw new IllegalStateException("Unsupported principal type");
}

This becomes the standard way to access the current user across the application.

What Improved

More predictable authentication

User identity is now:

immutable
consistent across requests
independent of user input

Better security model

The system no longer relies on fields that users can change.
Every request resolves to a database ID, which must exist.

Easier feature development

Adding support for:

email change
multiple authentication methods
external providers

is now straightforward.

What Was Costly

This wasn’t a small refactor.

It required:

updating JWT generation and parsing
rewriting authentication filter logic
replacing findByEmail across the codebase
adjusting services and flows that depended on email

It’s the kind of change that touches a lot of code and needs to be done consistently.

Things to Watch Out For

If you’re considering a similar change:

Old tokens
Tokens using email may stop working. You may need to force re-authentication.

Partial refactors
Mixing email-based and ID-based logic will lead to subtle bugs.

Tests
Without proper test coverage, it’s easy to introduce regressions in authentication flow.

Thanks for reading!

If you'd like to see Finovara development, check out my GitHub!

M4rc1nek / finovara-backend

Backend service for a personal finance management application

Finovara

Finovara is a financial management platform designed to help users effectively track analyze, and optimize their income, expenses, and savings The application provides a secure, bank-like experience focused on transparency, financial awareness, and long-term money planning.

🎯 Purpose of the Application

Finovara aims to support users in making better financial decisions by offering clear insights into their financial activity and helping them maintain control over their budgets and savings.

The platform focuses on:

organizing income and expenses in a structured way
visualizing financial data through charts and statistics
supporting saving goals and spending limits
providing a virtual wallet concept for daily financial management

🚀 Key Features

Secure user authentication and authorization
Income and expense tracking
Categorization of financial operations
Interactive charts and financial statistics
Reports summarizing spending and income trends
Virtual wallet management
Savings goals (e.g. piggy banks)
Spending limits and budget control
Scalable architecture prepared for future financial…

View on GitHub

How I Designed a Scalable Notification System with JSON Polymorphism in Spring Boot - Finovara

Marcin Parśniak — Thu, 16 Apr 2026 19:30:00 +0000

While working on my project Finovara, I recently implemented a flexible notification system that reacts to user actions — like reaching a savings goal in a piggy bank.

Instead of going with a rigid structure, I decided to build something extensible and future-proof.

🧠 The Problem

Users perform different actions in the system:

reaching a savings goal
completing financial milestones
(more coming soon…)

Each of these events should generate a notification, but with different payloads.

I didn’t want:

dozens of tables
messy conditional logic
tightly coupled notification handling

⚙️ The Approach

I used JSON polymorphism with Jackson to store notifications in a single table, while keeping type-specific structures.

Each notification implements a common interface:

public interface NotificationResponse {
    NotificationType type();
    LocalDate createdAt();
    String deduplicationKey();
}

And then I define specific types like this:

@JsonTypeName("PIGGY_BANK_GOAL_REACHED")
public record PiggyBankReachedDto(
        NotificationType type,
        LocalDate createdAt,
        PiggyBankGoalType goalType,
        String piggyBankName,
        Long piggyBankId,
        BigDecimal threshold
) implements NotificationResponse {

    @Override
    public String deduplicationKey() {
        return "%s:%d:%s:%s".formatted(type, piggyBankId, goalType, threshold);
    }
}

🧩 Generic Notification Engine

To avoid duplicating logic, I introduced a generic abstraction:

public abstract class ThresholdReachedService<E, C> implements NotificationCreator {
    protected static final BigDecimal REACHED_THRESHOLD = BigDecimal.valueOf(100);

    protected abstract List<E> fetchEntities(Long userId);

    protected abstract C calculate(E entity, Long userId);

    protected abstract BigDecimal getPercentage(C context);

    protected abstract NotificationResponse buildNotification(E entity, C context, Long userId);
    @Override
    public List<NotificationResponse> getNotifications(Long userId) {
        List<NotificationResponse> result = new ArrayList<>();

        for (E entity : fetchEntities(userId)) {
            C context = calculate(entity, userId);
            BigDecimal percentage = getPercentage(context);

            if (percentage.compareTo(REACHED_THRESHOLD) >= 0) {
                result.add(buildNotification(entity, context, userId));
            }
        }

        return result;
    }
}

This allows me to:

fetch domain entities
calculate progress
generate notifications only when a threshold is reached

💾 Persistence with Deduplication

One tricky part: avoiding duplicate notifications.

I solved it with a deduplicationKey:

.filter(dto -> !existingKeys.contains(dto.deduplicationKey()))
.filter(dto -> batchKeys.add(dto.deduplicationKey()))

This ensures:

no duplicates from previous runs
no duplicates within the same batch

🔄 Serialization Layer

Notifications are stored as JSON:

payload(toJson(dto))

and safely deserialized:

objectMapper.readValue(payload, NotificationResponse.class);

This gives me:

flexibility in adding new notification types
no schema changes needed
clean separation of concerns

✅ What I Gained

✔️ Extensible architecture
✔️ Clean domain separation
✔️ No schema migrations for new notification types
✔️ Easy to plug in new features

Thanks for reading, and check out my github!

M4rc1nek / finovara-backend

Backend service for a personal finance management application

Finovara

🎯 Purpose of the Application

Finovara aims to support users in making better financial decisions by offering clear insights into their financial activity and helping them maintain control over their budgets and savings.

The platform focuses on:

organizing income and expenses in a structured way
visualizing financial data through charts and statistics
supporting saving goals and spending limits
providing a virtual wallet concept for daily financial management

🚀 Key Features

Secure user authentication and authorization
Income and expense tracking
Categorization of financial operations
Interactive charts and financial statistics
Reports summarizing spending and income trends
Virtual wallet management
Savings goals (e.g. piggy banks)
Spending limits and budget control
Scalable architecture prepared for future financial…

View on GitHub

Reducing Duplication in Email Notification Settings with an Abstract Service in Spring Boot - Finovara

Marcin Parśniak — Thu, 09 Apr 2026 19:59:16 +0000

When working on user notification settings in my Spring Boot project, I noticed a lot of duplicated logic across different email notification services

Each type of notification (password change, etc.) was doing almost the same thing:

loading the user
reading notification settings
updating a boolean flag
sending an email conditionally
logging activity

So I decided to refactor it using an abstract base service.

Before refactor (problem)

Every service contained similar logic like this:

User user = userManagerService.getUserByEmailOrThrow(email);
NotificationEmailSettings settings = user.getNotificationEmailSettings();

settings.setNotifyOnPasswordChange(dto.enabled());

And then duplicated email sending + activity logic across multiple services.

This led to:

duplicated code
inconsistent behavior risk
harder onboarding for new notification type

Solution: AbstractNotificationEmailService

I introduced a template-based abstract service that handles the shared workflow.

Now the base class looks like this:

@RequiredArgsConstructor
public abstract class AbstractNotificationEmailService {

    protected final UserManagerService userManagerService;
    protected final NotificationEmailSender notificationEmailSender;

    @Transactional
    public void saveEmailNotification(String email, NotificationEmailDto dto) {
        User user = userManagerService.getUserByEmailOrThrow(email);
        NotificationEmailSettings settings = user.getNotificationEmailSettings();

        boolean enabled = isEnabled(dto);
        applySetting(settings, enabled);

        handleActivity(email, enabled);
    }

    public NotificationEmailDto getEmailNotification(String email) {
        User user = userManagerService.getUserByEmailOrThrow(email);
        NotificationEmailSettings settings = user.getNotificationEmailSettings();

        return mapToDto(settings);
    }

    public void sendEmail(User user) {
        notificationEmailSender.sendIfEnabled(
                user,
                this::isNotificationEmailSettingsEnabled,
                this::sendEmailToUser
        );
    }

    protected abstract boolean isEnabled(NotificationEmailDto dto);

    protected abstract void applySetting(NotificationEmailSettings settings, boolean value);

    protected abstract boolean isNotificationEmailSettingsEnabled(NotificationEmailSettings settings);

    protected abstract NotificationEmailDto mapToDto(NotificationEmailSettings settings);

    protected abstract void sendEmailToUser(User user);

    protected void handleActivity(String email, boolean enabled) {
        // optional override
    }
}

Example implementation

Each notification type now only defines its own behavior.

Example: password change notification

@Service
public class NotifyPasswordChangeService extends AbstractNotificationEmailService {

    private final PasswordChangeEmailService passwordChangeEmailService;
    private final SettingsActivityService settingsActivityService;

    public NotifyPasswordChangeService(
            UserManagerService userManagerService,
            NotificationEmailSender notificationEmailSender,
            PasswordChangeEmailService passwordChangeEmailService,
            SettingsActivityService settingsActivityService
    ) {
        super(userManagerService, notificationEmailSender);
        this.passwordChangeEmailService = passwordChangeEmailService;
        this.settingsActivityService = settingsActivityService;
    }

    @Override
    protected boolean isEnabled(NotificationEmailDto dto) {
        return dto.enabled();
    }

    @Override
    protected void applySetting(NotificationEmailSettings settings, boolean value) {
        settings.setNotifyOnPasswordChange(value);
    }

    @Override
    protected boolean isNotificationEmailSettingsEnabled(NotificationEmailSettings settings) {
        return settings.isNotifyOnPasswordChange();
    }

    @Override
    protected NotificationEmailDto mapToDto(NotificationEmailSettings settings) {
        return new NotificationEmailDto(settings.isNotifyOnPasswordChange());
    }

    @Override
    protected void sendEmailToUser(User user) {
        passwordChangeEmailService.sendEmail(user);
    }

    @Override
    protected void handleActivity(String email, boolean enabled) {
        settingsActivityService.createSettingActivity(
                email,
                enabled ? SettingActivityStatus.ENABLED : SettingActivityStatus.DISABLED,
                SettingType.NOTIFICATION_PASSWORD_CHANGED
        );
    }
}

What improved

After this refactor:

Better structure: shared logic is in one place
Less duplication: no repeated boilerplate across services
Easier extension:new notification = just extend abstract class
More consistency: same flow for every notification type

Thanks for reading, if you want check my github!

M4rc1nek / finovara-backend

Backend service for a personal finance management application

Finovara

🎯 Purpose of the Application

Finovara aims to support users in making better financial decisions by offering clear insights into their financial activity and helping them maintain control over their budgets and savings.

The platform focuses on:

organizing income and expenses in a structured way
visualizing financial data through charts and statistics
supporting saving goals and spending limits
providing a virtual wallet concept for daily financial management

🚀 Key Features

Secure user authentication and authorization
Income and expense tracking
Categorization of financial operations
Interactive charts and financial statistics
Reports summarizing spending and income trends
Virtual wallet management
Savings goals (e.g. piggy banks)
Spending limits and budget control
Scalable architecture prepared for future financial…

View on GitHub

Finovara - Building a Simple Chatbot in Spring Boot

Marcin Parśniak — Wed, 25 Mar 2026 16:37:24 +0000

Recently, I added a simple chatbot to my Finovara app that answers users’ finance-related questions.

No AI, no NLP libraries — just clean architecture, enums, and text files.

It works surprisingly well for the limited scope we need. Here’s how it’s built.

The Idea

The chatbot works like this:

A user asks a question.
The system normalizes the input.
It maps the question to a predefined entry.
The entry corresponds to a SmartReportType enum.
The enum is handled by a handler class.
The handler generates the actual response.

This makes the system:

Predictable
Easy to extend
Fast and lightweight

Core Architecture

The main entry point is:

  public String generateResponse(String email, String userQuestion) {
        User user = userManagerService.getUserByEmailOrThrow(email);

        SmartReportType type = smartReportQuestionService.getTypeFromQuestion(userQuestion);

        if (type == null)
            return "I’m not smart enough to answer this question. Please ask a question from the question book!";

        SmartReportHandler handler = handlers.get(type);

        if (handler == null) {
            return "Report type not supported";
        }

        return handler.generate(user.getId());
    }

Here’s what’s happening:

The question is mapped to a SmartReportType enum.
Each enum has its own handler.
The handler generates a response based on templates and user data.

This is basically a Strategy Pattern in action.

Mapping Questions to Enums

Instead of hardcoding questions in Java, they are stored in TXT files:

MONTH_SPENDING | how much did i spend this month
MONTH_SPENDING | monthly expenses
AVERAGE_DAY_SPENDING | average daily spending
EXPENSE_RATE | what percentage of my income is spent
SAVINGS_RATE | how much did i save

Loader Service:

questionMap.put(question, SmartReportType.valueOf(enumName));

Normalization:

private String normalize(String text) {
    return text.toLowerCase()
        .trim()
        .replace("?", "");
}

Thanks to this:

“How much did I spend?”
“how much did i spend”
“HOW MUCH DID I SPEND??”

all map to the same key.

Handlers: Business Logic

Each enum type has its own handler:

public interface SmartReportHandler {
    SmartReportType getType();
    String generate(Long userId);
}

Handlers are responsible for fetching user data and generating responses.

Example: Expense Rate

BigDecimal total = sumExpenses.multiply(BigDecimal.valueOf(100))
    .divide(sumRevenue, 2, RoundingMode.HALF_UP);

String template = templateService.getRandomResponse(SmartReportType.EXPENSE_RATE);
return template.replace("{amount}", total.toString());

Dynamic Responses (Templates)

Responses are stored in text files instead of being hardcoded:

You spent {amount} this month.
Your total expenses are {amount}.
Your savings rate is {amount}%.

Randomization makes replies feel less repetitive:

return responses.get(random.nextInt(responses.size()));

*Thanks for reading! *

If you’re curious to see the full project or try it yourself, check out the code on GitHub:

M4rc1nek / finovara-backend

Backend service for a personal finance management application

Finovara

🎯 Purpose of the Application

Finovara aims to support users in making better financial decisions by offering clear insights into their financial activity and helping them maintain control over their budgets and savings.

The platform focuses on:

organizing income and expenses in a structured way
visualizing financial data through charts and statistics
supporting saving goals and spending limits
providing a virtual wallet concept for daily financial management

🚀 Key Features

Secure user authentication and authorization
Income and expense tracking
Categorization of financial operations
Interactive charts and financial statistics
Reports summarizing spending and income trends
Virtual wallet management
Savings goals (e.g. piggy banks)
Spending limits and budget control
Scalable architecture prepared for future financial…

View on GitHub

Deploying Finovara on Docker and fixing a critical bug.

Marcin Parśniak — Fri, 20 Mar 2026 21:35:33 +0000

I recently decided to move my Spring Boot app Finovara to Docker.

At first it was just supposed to be a small improvement to the setup.
In reality, it turned into a debugging session that took way longer than I expected.

Why I even bothered with Docker

There were a few reasons behind this:

I wanted more control over the environment
I needed a separate database (finovara-test) for automated tests
I was tired of manually setting everything up locally
and I wanted something closer to a real production setup

Initial setup

I started with a simple PostgreSQL container and connected my app to it.

Here’s a simplified version of what I used:

services:
  finovara-db:
    image: postgres:15
    container_name: finovara-db
    restart: always
    environment:
      POSTGRES_DB: finovara
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    ports:
      - "5432:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 10

Dockerfile:

FROM eclipse-temurin:21-jdk
WORKDIR /app
COPY target/*.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

Everything started without issues.
Database was running, app connected, no errors.

So I thought I was done.

The moment things got weird

I made some changes in the app, rebuilt everything, ran it again and nothing changed.

same responses
same data
same behavior

At this point I was pretty sure I messed something up.

What I thought vs what it actually was

My first guess was Docker caching.
Seemed like the obvious explanation.

But after digging a bit more, it turned out to be something else entirely.

The app was connecting to a completely different database than I expected.

Everything looked correct:

same DB name
same user
same config

So from the outside it looked like everything was fine, but I was basically working on one database and checking another.

Fixing it

The fix wasn’t one single thing, more like a combination of small adjustments:

I changed the password in my .env file
I changed the port, because something else was already using 5432
I cleaned up and adjusted the docker-compose config
and most importantly, I actually verified which database the app connects to

After that, everything finally made sense again and changes started showing up immediately.

Thanks for reading and visit my github!

M4rc1nek / finovara-backend

Backend service for a personal finance management application

Finovara

🎯 Purpose of the Application

Finovara aims to support users in making better financial decisions by offering clear insights into their financial activity and helping them maintain control over their budgets and savings.

The platform focuses on:

organizing income and expenses in a structured way
visualizing financial data through charts and statistics
supporting saving goals and spending limits
providing a virtual wallet concept for daily financial management

🚀 Key Features

Secure user authentication and authorization
Income and expense tracking
Categorization of financial operations
Interactive charts and financial statistics
Reports summarizing spending and income trends
Virtual wallet management
Savings goals (e.g. piggy banks)
Spending limits and budget control
Scalable architecture prepared for future financial…

View on GitHub

Liquibase in Spring Boot – Developer's Guide

Marcin Parśniak — Tue, 10 Mar 2026 08:05:12 +0000

Liquibase in Spring Boot – Developer's Guide

Managing database schema changes can seem simple at first… until it isn’t. A quick ALTER TABLE here and there might work with one developer, but once you have multiple environments—dev, staging, prod—things get messy fast.

This is where Liquibase comes in.

In this guide, I’ll walk you through:

What Liquibase is and why it matters
Setting it up in Spring Boot
Writing migrations safely
Managing different environments

What is Liquibase?

Liquibase is essentially Git for your database schema. Instead of running SQL scripts manually and hoping everyone runs them correctly, you define changes in a structured format and Liquibase tracks which ones have been applied.

Example XML changeset:

<changeSet id="add-phone-number" author="dev">
    <addColumn tableName="users">
        <column name="phone_number" type="varchar(20)"/>
    </addColumn>
</changeSet>

Liquibase keeps track of applied migrations in a table called DATABASECHANGELOG, ensuring:

Changes are applied only once
Order is maintained
Rollbacks are possible

Why use Liquibase with Spring Boot?

Some key benefits:

Consistent environments – dev, staging, and prod stay in sync
Migration history – see who changed what and when
Automatic migrations – Spring Boot can run them on startup
Rollbacks – undo changes safely if needed

Adding Liquibase to your project

Maven:

<dependency>
    <groupId>org.liquibase</groupId>
    <artifactId>liquibase-core</artifactId>
</dependency>

Gradle:

implementation 'org.liquibase:liquibase-core'

Spring Boot will automatically detect Liquibase and run migrations.

Configuration

In application.yml (safe YAML formatting):

spring:
  liquibase:
    change-log: "classpath:/db/changelog/changelog.xml"
    contexts: "dev"

Typical project structure:

resources
 └ db
    └ changelog
        └ changelog.xml

Master changelog with multiple changesets

Instead of separate XML files, you can put all changesets in a single file: changelog.xml

<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
                   http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.8.xsd">

    <changeSet id="create-users" author="you">
        <createTable tableName="users">
            <column name="id" type="bigint">
                <constraints primaryKey="true"/>
            </column>
            <column name="email" type="varchar(255)">
                <constraints nullable="false"/>
            </column>
            <column name="created_at" type="timestamp"/>
        </createTable>
    </changeSet>

    <changeSet id="add-email-index" author="you">
        <createIndex indexName="idx_users_email" tableName="users">
            <column name="email"/>
        </createIndex>
    </changeSet>

    <changeSet id="add-phone-column" author="you">
        <addColumn tableName="users">
            <column name="phone_number" type="varchar(20)"/>
        </addColumn>
        <rollback>
            <dropColumn tableName="users" columnName="phone_number"/>
        </rollback>
    </changeSet>

    <changeSet id="insert-test-data" author="you" context="you">
        <insert tableName="users">
            <column name="id" valueNumeric="1"/>
            <column name="email" value="test@example.com"/>
        </insert>
    </changeSet>

</databaseChangeLog>

Using SQL instead of XML

You can also write all changesets in a single formatted SQL file:

-- liquibase formatted sql
-- changeset dev:create-users
CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    email VARCHAR(255) NOT NULL,
    created_at TIMESTAMP
);

-- changeset dev:add-email-index
CREATE INDEX idx_users_email ON users(email);

-- changeset dev:add-phone-column
ALTER TABLE users ADD COLUMN phone_number VARCHAR(20);
-- rollback: ALTER TABLE users DROP COLUMN phone_number;

Best practices

Never edit executed migrations – migrations are immutable
One changeset = one change – separate tables, columns, and indexes
Number your files if using multiple files – avoids Git conflicts
Test locally – drop the DB, run the app, ensure migrations work from scratch
Be careful on production – avoid ALTER COLUMN TYPE, DROP COLUMN, or NOT NULL on large tables

Liquibase vs Flyway

Feature	Liquibase	Flyway
XML/YAML/JSON	✔	✖
SQL	✔	✔
Rollback	✔	limited

Flyway is simpler but Liquibase is more flexible for enterprise setups.

Conclusion

Liquibase is a lifesaver for keeping database schema consistent across environments. Stick to the golden rules:

immutable migrations
one change per changeset
test migrations locally

Thanks for reading!

Revenue test (JUnit5) - Finovara

Marcin Parśniak — Sat, 07 Mar 2026 10:56:13 +0000

Hello!

After the latest update to my project, I decided it was the perfect time to finally start writing tests for Finovara.

So far, I've written tests for the main methods.
On average, I run 2-3 tests per method, which seems like a good compromise. I cover both the happy path and a few edge cases and alternate flows—basically, I try to make sure everything works as expected, regardless of the situation.

Overall, I'm aiming for 70-80% code coverage, though this may change as I add more tests and improve what I already have.

Example of a simple test:

@Test
void shouldAddRevenueSuccessfully() {
        RevenueDTO dto = new RevenueDTO(null, null, new BigDecimal("100"), RevenueCategory.SALARY, null, "test income");
        String email = "test@test.com";
        User user = new User();

        when(timeConfig.clock()).thenReturn(Clock.systemDefaultZone());
        when(userManagerService.getUserByEmailOrThrow(email)).thenReturn(user);

        revenueService.addRevenue(dto, email);

        verify(walletService).addBalanceToWallet(email, dto.amount());
        verify(revenueActivityService).createRevenueActivity(eq(email), eq(RevenueActivityType.ADDED_REVENUE), any(Revenue.class));
        verify(revenueRepository).save(any(Revenue.class));
        verify(revenueScoringService).recalculateScore(email);
        verify(autoPaymentsService).handleRevenuePiggyBankAutomation(email, dto.amount(), AutoPaymentsMode.APPLY);
    }

Next, I plan to write expense tests. I'll see how it goes

Thanks for reading, and please visit my GitHub:

M4rc1nek / finovara-backend

Backend service for a personal finance management application

Finovara

Finovara is a financial management platform designed to help users effectively track analyze, and optimize their income, expenses, and savings The application provides a secure, bank-like experience focused on transparency, financial awareness, and long-term money planning.

🎯 Purpose of the Application

Finovara aims to support users in making better financial decisions by offering clear insights into their financial activity and helping them maintain control over their budgets and savings.

The platform focuses on:

organizing income and expenses in a structured way

visualizing financial data through charts and statistics

supporting saving goals and spending limits

providing a virtual wallet concept for daily financial management

🚀 Key Features

Secure user authentication and authorization

Income and expense tracking

Categorization of financial operations

Interactive charts and financial statistics

Reports summarizing spending and income trends

Virtual wallet management

Savings goals (e.g. piggy banks)

Spending limits and budget control

Scalable architecture prepared for future financial…

View on GitHub

User Notification Settings - Finovara

Marcin Parśniak — Thu, 05 Mar 2026 22:35:56 +0000

Hello everyone!

In the latest update to Finovara,
I implemented user notification settings.
This feature allows users to decide whether they want to receive email notifications for important account events.

What this feature does

Users can now enable or disable notifications for important events happening in their account.

When notifications are enabled and the user:

changes their password
changes username
deleted account

the system will send an email notification to the address assigned to his account informing his of the change.

Example of mail sending method:

 @Async
    public void sendEmail(User user, String subject, String templatePath, String username, String email) {
        try {
            MimeMessage message = javaMailSender.createMimeMessage();
            MimeMessageHelper helper = new MimeMessageHelper(message, true, "UTF-8");

            helper.setTo(user.getEmail());
            helper.setFrom("Finovara <" + senderAddress + ">");
            helper.setReplyTo(senderAddress);
            helper.setSubject(subject);

            String html = loadTemplate(templatePath, username, email);
            helper.setText(html, true);

            javaMailSender.send(message);

        } catch (Exception e) {
            throw new RuntimeException("Failed to send email", e);
        }
    }

Example loadTemplate:

 private String loadTemplate(String templatePath, String username, String email) {
        try {
            ClassPathResource resource = new ClassPathResource(templatePath);
            try (InputStream inputStream = resource.getInputStream()) {
                String html = new String(inputStream.readAllBytes(), StandardCharsets.UTF_8);

                if (username != null) {
                    html = html.replace("{{username}}", username);
                }
                if (email != null) {
                    html = html.replace("{{email}}", email);
                }
                return html;
            }
        } catch (Exception e) {
            throw new RuntimeException("Failed to load email template", e);
        }
    }

Thanks for reading!

I encourage you to take a look at the process of creating the Finovara application at: https://github.com/M4rc1nek/finovara-backend

Moving from Hibernate Auto-DDL to Liquibase - Finovara

Marcin Parśniak — Tue, 03 Mar 2026 18:54:06 +0000

Hello!

For a long time in my Spring Boot project, I relied on

hibernate.ddl-auto = update

It was simple.
Change an entity → restart the app → the database updates itself.

But when the project grew to 18 entities, I realized something important:

I had zero control over my database history.

So I decided to switch to Liquibase.

What I Changed

Disabled Hibernate auto schema updates

spring:
  jpa:
    hibernate:
      ddl-auto: none

From that moment, Hibernate stopped modifying the database structure.

2. Enabled Liquibase

spring:
  liquibase:
    enabled: true
    change-log: classpath:db/changelog/changelog.xml

3. Added simple changeSets

<changeSet id="1-create-users" author="Marcin Parśniak">
        <createTable tableName="users">
            <column name="id" type="BIGINT" autoIncrement="true">
                <constraints primaryKey="true" nullable="false"/>
            </column>
            <column name="username" type="VARCHAR(255)">
                <constraints nullable="false" unique="true"/>
            </column>
            <column name="password" type="VARCHAR(255)">
                <constraints nullable="false"/>
            </column>
            <column name="email" type="VARCHAR(255)">
                <constraints nullable="false" unique="true"/>
            </column>
            <column name="created_at" type="TIMESTAMP"/>
            <column name="profile_image_path" type="VARCHAR(500)"/>
        </createTable>
    </changeSet>

Now Liquibase manages the schema.

If you want to see how im doing it, check out my github profile:

M4rc1nek / finovara-backend

Backend service for a personal finance management application

Finovara

🎯 Purpose of the Application

Finovara aims to support users in making better financial decisions by offering clear insights into their financial activity and helping them maintain control over their budgets and savings.

The platform focuses on:

organizing income and expenses in a structured way
visualizing financial data through charts and statistics
supporting saving goals and spending limits
providing a virtual wallet concept for daily financial management

🚀 Key Features

Secure user authentication and authorization
Income and expense tracking
Categorization of financial operations
Interactive charts and financial statistics
Reports summarizing spending and income trends
Virtual wallet management
Savings goals (e.g. piggy banks)
Spending limits and budget control
Scalable architecture prepared for future financial…

View on GitHub

Reccuring Revenue - Finovara

Marcin Parśniak — Mon, 02 Mar 2026 21:27:00 +0000

Hello everyone!

A while ago, I added a new setting to the Finovara app.

What did I add?

I added a user setting for recurring revenue.

The user specifies the:

recurring revenue amount
revenue category
start date
frequency of revenue generation (daily, weekly, monthly)

How does it work?

The scheduler runs cron daily (currently every minute as a test, but will run daily at midnight).

The cron runs and checks if the revenue generation date matches.
If so, we check the condition in the code.
If it matches, a recurring revenue is created.

This is what an example implementation in a processor looks like:

for (User user : users) {
            RevenueSettings settings = user.getRevenueSettings();
            if(settings == null) continue;
            while(settings.isRecurringRevenuesEnable() && settings.getNextExecutionDate() != null && !settings.getNextExecutionDate().isAfter(today)){
                createRecurringRevenue(user, settings);
                switch (settings.getRecurringStrategy()) {
                    case DAILY -> settings.setNextExecutionDate(settings.getNextExecutionDate().plusDays(1));
                    case WEEKLY -> settings.setNextExecutionDate(settings.getNextExecutionDate().plusWeeks(1));
                    case MONTHLY -> settings.setNextExecutionDate(settings.getNextExecutionDate().plusMonths(1));
                }
            }
        }

Finovara - Piggy banks activity logs.

Marcin Parśniak — Fri, 27 Feb 2026 21:31:35 +0000

Hey everyone 🙂

I’ve been working on another improvement in my Finovara project — this time around Piggy Banks.

Recently I added something I called Activity tracking for savings. The idea was simple: when people save money, they should clearly see what actually happened in their piggy banks.

So now, whenever a user:

• puts money into a piggy bank
• withdraws funds
• creates a new piggy bank
• deletes one
• or performs any savings-related action

it all gets recorded in their activity history.

Each entry shows what happened, when it happened, and the amount involved. Nothing fancy, just clear visibility so users don’t have to guess where their money moved.

While working on this, I also cleaned up something on the backend side.

Previously, every saving feature had to be saved separately. It worked, but it felt messy and required multiple API calls.

So I introduced a single endpoint that lets the frontend save all piggy bank settings in one request.

Now it handles things like:

• automatic savings rules
• transaction round-ups
• goal completion behavior

The backend simply receives one DTO with all sections and passes them to the right services internally.

It made the whole flow much simpler, both for the API and for the frontend.

Thanks for reading! :D

Finovara - Limits activity logs.

Marcin Parśniak — Wed, 25 Feb 2026 20:13:46 +0000

Hi everyone,
In the latest update of my Finovara project, I added more logs for user activities about limits.
How does it work?

As soon as a user:
• Adds a limit
• Removes a limit
• Edits a limit

They can see all their account activities.

A sample JSON looks like this:

{
"limitActivityType": "ADDED_LIMIT",
"limitType":  "DAILY",
"amount": 1500.00,
"previousAmount": 1000.00,
"date": "2026-02-25T14:30:00"
}

Records are deleted from the database every month thanks to the scheduler and cron job set in the .yml file.
Here's the link to the commit related to this update: https://github.com/M4rc1nek/finovara-backend/commit/ce42ab006d46d0c309d3806ddf83498065cbd3ea

Thanks for reading!