Dev Log: June 21 Wrap-up

Overview

Today was one of those days where I spent way more time wrestling with environment variables and connection strings than actually writing logic. It was all about getting the production environment stabilized on Railway, which turned out to be a bit of a game of trial and error with how PostgreSQL and MongoDB talk to Spring.

What I Worked On

The PostgreSQL connection string saga

I spent a good chunk of the afternoon fighting with the PostgreSQL datasource configuration. Initially, I tried to keep it simple by just prepending jdbc: to the standard DATABASE_URL provided by the platform. On paper, it looks fine, but the JDBC driver for Postgres is notoriously picky when credentials (user:pass) are embedded directly in the URL—it often results in a weird UnknownHostException because it fails to parse the host correctly.

After a few failed deployments, I decided to stop trying to force the single-string approach. I switched to using individual environment variables for the host, port, and database name. It's a bit more verbose in the YAML, but it’s much more reliable because the driver gets a clean URL and handles the credentials separately.

# A much cleaner way to handle the production datasource
datasource:
  url: jdbc:postgresql://${DB_HOST}:${DB_PORT}/${DB_NAME}
  username: ${DB_USER}
  password: ${DB_PASS}
  hikari:
    maximum-pool-size: 5 # Keeping this lean for the free tier

Squashing MongoDB connection quirks

Once the relational DB was happy, I noticed the MongoDB connection was acting up. The MONGO_URL I was using didn't include a specific database path, so the app didn't know which database to default to. I had to explicitly set the database property in the production profile to ensure everything was being routed to the correct spot. It's a small fix, but it’s exactly the kind of thing that makes you scratch your head for twenty minutes when you're wondering why your collections aren't appearing.

Production hardening

I finally got around to properly split out the application-prod.yml settings. I dialed back the logging levels—nobody needs to see every single Hibernate SQL trace in production—and tuned the HikariCP pool. Since I'm running on a smaller instance, I capped the maximum pool size to 5. There’s no point in having a massive connection pool if the underlying hardware is going to struggle to keep up. I also enabled some Flyway retries to handle those brief moments where the database might not be ready the exact second the app boots up.

Wrapping Up

Config work is rarely the highlight of the week, but seeing that first clean 'Started Application' log in the production console made the headache worth it. Everything feels a lot more solid now that the environment-specific quirks are ironed out. Tomorrow, I’m looking forward to getting back into the actual feature code.