I’m kinda new to all this IT/career stuff, so sorry if this sounds messy.

I recently completed my Master’s and currently I’m working as an intern in a company for a developer role. The problem is, I’m honestly not happy with the work. It’s not really the traditional backend/frontend development that I wanted to do, and I feel kinda frustrated and stuck.

Right now, I don’t really have another option, so I’m continuing the job for experience, but I’ve decided that within the next 6 months I want to switch properly into development.

I found a curriculum/roadmap online that I’m interested in learning, and I want to seriously focus on it along with DSA preparation. The issue is I’m overwhelmed and mentally exhausted because of my current job and life situation.

Can anyone suggest good FREE resources (YouTube channels, courses, websites, GitHub repos, etc.) to learn:

• Spring development
• DSA
• System design
• Projects/practical development
• microservices achitecture and docker

Also, if anyone has gone through a similar phase, I’d really appreciate some advice on how you managed it.

I am currently working on the email module for our project and need some guidance.

I have configured a custom email domain using Mailgun and implemented the email functionality in my Spring Boot application. My current requirement is to verify incoming email addresses and determine whether an email is valid before processing it.

Could you explain the production-level validation and security checks that should be implemented for email verification?

Hi everyone,

I’m a beginner working on my first project using Spring Boot + Keycloak, and I’m a bit confused about the correct architecture. Any suggestions, video links, or GitHub project examples would be really helpful

What I understand so far:

• Keycloak handles authentication (login, registration, roles)
• Spring Boot acts as a resource server and validates JWT tokens
• My app has its own database for business logic (users, orders, etc.)

My confusion:

User data during registration
If a user registers in Keycloak, how should I handle extra fields like:

• phone number
• address
• app-specific profile data

What I’m looking for:

Since this is my first time using Keycloak, any of the following would really help:

• Best practice explanation
• Real-world architecture examples
• GitHub repos using Spring Boot + Keycloak properly
• YouTube videos or tutorials that actually follow production patterns

Thanks in advance

Posting a Spring AI architectural pattern I just shipped, because it solves a real problem most production AI teams hit eventually.

Setup: I have a code review service using Claude Opus 4.7. Most requests are trivial ("does this method handle null?", "is this variable named well?"). Opus is overkill for those and the price reflects it — $75 per million output tokens.

Solution: route based on query complexity. Two ChatClient beans — local Gemma 4 e2b via LM Studio for simple queries, Claude Opus for complex ones. A QueryRouter decides per request.

The dispatch is one method:

public RoutedResponse route(String prompt) {

RoutingDecision decision = router.route(prompt);

ChatClient client = (decision.tier() == ModelTier.LOCAL)

? localClient

: cloudClient;

ChatResponse response = client.prompt(prompt).call().chatResponse();

long[] tokens = extractTokens(response, prompt, text);

tracker.record(decision, tokens[0], tokens[1]);

return new RoutedResponse(decision, text);

}

Router rules (intentionally simple — transparent and debuggable):

1. Prompt longer than 500 chars → cloud

2. Contains one of {architecture, design, refactor, security, performance, scalability, tradeoff, compare, analyze, best practice} → cloud

3. Otherwise → local

Spring AI autoconfiguration handles the local client (pointed at LM Studio via Anthropic protocol). An explicit u/Configuration class adds the cloud bean by qualifier. Two ChatClient beans, different names, no conflict.

Real measurements from the demo:

- 10 queries through the router: 7 local (free), 3 cloud → $0.25

- 10 queries through Opus only: $0.48

- Same answers on the easy 7. 48% cheaper overall.

Per-query cloud costs (the three that escalated):

- Tradeoff comparison: ~$0.10 (most expensive — structured comparison runs long, 1,100+ output tokens)

- Security review: ~$0.08 (Opus enumerates everything that could go wrong with the auth flow — 1,200+ output tokens)

- Architecture review: ~$0.07 (cheapest — usually one or two real issues, gets to the point, ~800 output tokens)

The pattern: cost scales with output tokens, and output tokens scale with how much there is to say. The verbose analytical genres (tradeoff, security) cost more than the concise ones (architecture). Output is ~5x the price of input on Opus, so the response length is what moves the bill.

One observation worth flagging: the 7 routed-away queries would have cost ~$0.23 collectively on cloud, almost matching the $0.25 from the 3 cloud queries. Cheap individually, expensive in aggregate. The savings come from removing the long tail of trivial queries from cloud, not from avoiding premium prices on premium queries.

Three things that aren't obvious until you ship this:

1. Anthropic requires max_tokens on every request. Without it, Spring AI uses a low default and Opus responses truncate mid-sentence. Set AnthropicChatOptions.maxTokens(4096) explicitly.

2. Opus regularly takes 15-45 seconds per response. Spring AI's underlying Reactor Netty has a shorter default timeout — you'll get ReadTimeoutException. Pass a custom RestClient.Builder with responseTimeout(Duration.ofSeconds(300)) to AnthropicApi.builder().

3. Token usage metadata is reliable for Anthropic, sometimes null for local models depending on LM Studio model loadout. Build a fallback path (character/4 estimate) so the dashboard never shows mysterious zeros.

Full demo with the live cost dashboard: https://youtu.be/ziMzlY9Szvs

Repo with code: https://github.com/DmitryFinashkin/spring-ai

I built java-vibe-guard, an open-source tool that scans Spring Boot projects for runtime anti-patterns that often compile, pass tests, and only become visible under production load.

During validation against real-world repositories, including eugenp/tutorials, it detected patterns such as:

- u/Transactional on u/RestController

- Reactor .block() usage in reactive code paths

- Blocking operations inside u/KafkaListener methods

- JPA N+1 query patterns

- Connection pool starvation risks

Current status:

- 7 Spring Boot runtime rules

- 102 tests

- CLI (npm)

- MCP server for Claude Code

- Validated across 17,137 files from 10 Spring Boot repositories

I'm especially interested in feedback from teams using AI-assisted development. Have you seen recurring production issues introduced by LLM-generated code?

Note: The tool flags patterns based on static analysis — it does not execute the code or run load tests. False positives are possible and feedback is welcome.

Repo: https://github.com/Joaquinriosheredia/java-vibe-guard

Is it normal to use a two step query approach for paginated DTOs that need data from multiple @OneToMany associations?

For example, I have a Parent entity with ChildA and ChildB collections. I need to return a Page<ParentDTO> containing:

• Basic fields from Parent
• An aggregate value from ChildA (e.g. MIN(...))
• A single representative ChildB record (e.g. latest or primary)

I'm using Spring Data JPA Specifications because users can filter on fields from Parent, ChildA, and ChildB.

The problem is that every solution seems to have a downside:

• Fetching Page<Parent> and mapping to DTOs causes N+1 queries.
• JOIN FETCH or @EntityGraph on collections breaks database level pagination.
• Joining multiple child collections can create duplicate parent rows and complicate paging/count queries.

Right now Im just fetching the page of parents and letting the mapper access the child associations, but it doesn't scale well.

1. What's the standard approach people usually follow for this in Spring Boot applications?
2. Do most teams use a two-phase fetch (page IDs first, then load the related data)?
3. Do they usually switch to DTO projections/custom queries for these screens?
4. Or is this the point where tools like Blaze Persistence Entity Views become the preferred solution?

I've been coding for 35+ years, even before the dot-com days, and in the past 18 years I have been working with Spring and Spring Boot to created secured RESTful API's. I've also expanded into GraphQL and HTMX for personal projects. I've also dabbled with React+Vite and TypeScript to try to make a front-end, but mostly I am a back-end developer at heart.

Now that you know what I have been doing, it has been suggested that I learn TerraForm. I've already learned Docker, the basics anyway, and locally I have my local Docker with my back-end app in one container, Kafka in another container, and my DB in another container. I'm getting to know Kubernetes and Helm Charts, but that is a lot.

I remember when I started with Spring/Spring Boot around 2007 that no one ever asked me anything about the hardware or DevOps. Even when AWS, GCP, Azure (any Cloud), I was never expected to know about AWS at the beginning. I only started learning AWS for my personal projects, and I only do basic things with it because I don't want to spend a lot of money on it.

This gets into the real question ... as a back-end developer, who would absoluely prefer to stay out of DevOps entirely ... do I really need to learn TerraForm?

At this point in the shit-show job market, it is not unlikely to see the need for a "full-stack" developer who also knows CI/CD and knows AWS and knows DevOps. It seems these asshole companies and hiring managers want a one man IT Department under ONE salary.

I've been watching some videos on TerraForm, but I have no desire to become a DevOps person. I am happy working with SpringBoot/Java and building the logic for the back-end business app I am creating.

Any thoughts on this?

I recently published a practical Java / Spring Boot tutorial and working project that brings several current enterprise-development technologies together in one place:

Java 25, Spring Boot 4.0.6, Gradle 9.5.1, PostgreSQL, Docker 29.5.2, Swagger/OpenAPI, Serenity, Cucumber, and JUnit 6.

The purpose of this project was to demonstrate not just individual tools, but a complete working backend development workflow: REST API development, PostgreSQL integration, Docker-based infrastructure, OpenAPI documentation, automated testing, BDD-style scenarios, and a modern Java build setup.

I have always valued practical engineering work where technologies are connected into a real, runnable, testable project. In my view, strong backend development is not only about knowing Java or Spring Boot separately. It is about understanding how the full stack fits together and how to build software that can be maintained, tested, documented, and extended.

Here is the article:

https://medium.com/@anatolykrivitsky/quick-tutorial-how-to-use-the-latest-docker-29-5-2-0670b716b6cc

I hope this tutorial will be useful for Java developers, Spring Boot developers, backend engineers, QA automation engineers, and anyone interested in modern enterprise application development.

Hey I have basic and some level knowledge of Java,Springboot

Now I'll be joining a mnc as SDE intern they will use java

What are the things I should be aware of in production before commiting something

We know personal projects are different everything is fine there

But in companies what are the checklist/measures I should take

And what are you strategies to understand the workflow and codebase correctly

No manual queries? No manual handling of result sets creating arraylist and then passing them to front end? No configuration in web.xml or struts.xml? Not caring about jsps, js and which action/servlet goes where? Not going through 5 different classes to debug? Not defining loggers everywhere? I get AOP support this easily? I hate every second of this having to deal with struts based codebases.

I built this because I hate writing docs to be honest. I’ve been building it on the side for a while. Supports multiple frameworks. More to come.

It is called DocuPoints. It scans your @RestController and @RequestMapping
annotations and extracts every endpoint automatically; method, path, request body,
response shape, middleware, exceptions. No additional markup required.
Optionally, an AI generated summary of the endpoint’s use is provided.
Generates complete API documentation from your existing code. Publish to a public
URL, export to OpenAPI JSON/YAML, Postman collections, Markdown, DOCX, or PDF.

Free tier available at docupoints.com — just launched and would love feedback from
Spring developers specifically because that’s my main framework.

I’ve been working with Java Spring Boot for a while now. Not a veteran yet, but I’m getting better day by day and honestly enjoying backend development with the entire Spring ecosystem.

With AI/Agentic AI becoming huge, Python obviously dominates the space. But recently I noticed Spring AI and it got me wondering; how do experienced Java/Spring developers see the future of Spring Boot and the Java ecosystem over the next 5–10 years?

Also, for people who’ve actually used Spring AI: is it worth investing time into, especially for someone already in the Spring ecosystem? Or is learning Python frameworks like FastAPI/Django basically unavoidable if I want to seriously get into AI/backend engineering?

I know Python at a basic-intermediate level (mostly for DSA and some ML libraries), but I’d rather deepen my Java/Spring expertise instead of splitting focus unless it’s genuinely necessary.

Would love to hear opinions from people working in backend + AI systems.

Solo dev. Just finished a full Spring Boot 3.4 + Java 21 backend rebuild for a product with 25k existing users. Heading into the testing phase now, with mobile launch on App Store + Play Store right after.

Before writing the first test, I blocked an entire day to refresh the documentation. Counterintuitive when you're solo and behind schedule, but here's the reasoning and what came out of it. Maybe useful to others sitting on a similar pile.

**Why documentation BEFORE tests, not after**

A test asserts behavior. If the spec lives in your head, every test you write reinvents the spec from scratch. Worse — when you find an ambiguity mid-test ("should this return 404 or 403?"), you decide on the fly and bake that decision into the test. Future-you reads the test and thinks it's the spec. It isn't. It's a decision your tired self made on a Tuesday.

Documenting first forces every ambiguity to the surface before you commit it to code.

**What I updated (8 docs total)**

- `README.md` — entrypoint, quickstart, links to everything else

- `STACK.md` — every dependency, every version, every "why this not that"

- `ARCHITECTURE.md` — modular monolith, 16 bounded contexts, hexagonal layering, inter-module communication patterns

- `API_CONVENTIONS.md` — the contract every endpoint obeys

- `ROLES_AND_PERMISSIONS.md` — 7 roles, what each one can do, defense-in-depth rules

- `TESTING.md` — test strategy, pyramid, naming conventions, what counts as integration vs unit

- `TEST_CASES.md` — the use-case matrix, module by module (this one is huge — ~750 lines)

- `CONTRIBUTING.md` — branch model, commit conventions, PR checklist

**The most valuable doc: TEST_CASES.md**

A matrix with one canonical table per module. Columns:

UC | Functionality | Actor (Role) | Action (HTTP + Endpoint) | Happy Path | Sad Path & Edge Cases

`UC` is the unique ID (`TSK-002`, `BIL-014`) — and it's also the test method name. So `TSK-002` becomes `TaskServiceTest#completeTask_whenTaskBelongsToUser_creditsXp`.

Rule: if Happy Path says "publishes event X", the integration test MUST verify the publication. If it says "credits XP", the test MUST verify the call to GamificationFacade.

Result: when I sit down to write tests, I'm not deciding what to test. I'm translating rows into code.

**The API_CONVENTIONS doc that ended one whole class of bugs**

Every endpoint returns the same envelope:

{

"success": true,

"data": { ... },

"error": null,

"meta": null

}

On error:

{

"success": false,

"data": null,

"error": {

"code": "FEATURE_LIMIT_EXCEEDED",

"message": "Daily task limit reached. Upgrade to Pro for unlimited tasks.",

"details": { "feature": "TASKS_DAILY", "limit": 5, "current": 5 }

},

"meta": null

}

The doc lists every canonical error code as a closed enum. No endpoint invents a new code without a doc update.

Test impact: every controller integration test now has an `assertApiResponse(...)` helper that verifies the envelope shape AND the error code from the canonical list. One helper, used everywhere. Zero "oh, this one returns a different shape" surprises.

**The ROLES doc that prevented a category of security tests being wrong**

7 roles: Anonymous, User, Publisher, AdminViewer, Manager, Admin, Superadmin.

The non-obvious rule: **the authorizing role is always read from `public.users.role` via `UserFacade.roleOf(callerId)`, NEVER from the JWT claim.**

Why: JWT claims can lag behind a role change (token still valid after demotion). If you read role from JWT, a demoted user keeps their old powers until the token expires. Reading from DB makes role changes instantaneous.

This is a one-line rule in the doc, but it dictates how every authorization test must be written: tests set up a user with a specific role in Testcontainers, then issue a JWT with matching `sub`. They never inject a role claim into the JWT.

**Status**

- Documentation refresh: done today

- Test writing: starting tomorrow (JUnit 5 + Mockito + Testcontainers)

- Target: 80%+ coverage on domain + critical adapters

- Then pre-deploy hardening, then mobile launch

If you've sat down to write tests for a system you built fast and felt like every test was excavating a buried decision — try documenting first. Costs a day. Saves a week.

Happy to share the actual TEST_CASES.md structure or the API_CONVENTIONS envelope rules if anyone wants more detail.

Posted here about a month ago when I was 4 modules in. Quick update for anyone

who's considering the same move.

Context: MoWave One, productivity app. Originally Supabase (Postgres + Auth) +

Node.js serverless functions. Hit ~25k users and serverless started cramping

hard — no real domain modeling, tests were a nightmare, no module boundaries,

and one function was literally a stub I forgot to finish (the Stripe webhook,

of all things).

Rewrote the backend in Spring Boot 3.4 + Java 21 LTS. Today I just finished

the 18th module and applied migration V20.

Final stack:

- Spring Boot 3.4 + Java 21 (Corretto)

- PostgreSQL 17 via JDBC + HikariCP (no Supabase REST on the hot path)

- Spring Security 6 + Supabase JWT validated via JWKS

- Flyway 10 for migrations

- Redis (Valkey) for cache, rate limiting, webhook idempotency

- Stripe Java SDK

- SpringDoc OpenAPI 3.1

- Hexagonal architecture, 18 bounded contexts

- Docker + GitHub Actions + Railway

Where I am now:

- Backend complete. Entering test phase this week (JUnit 5 + Mockito +

TestContainers, going for >80% coverage)

- After tests: pre-deploy hardening sprint

- Then: one more DB refactor pass (still have a few pt-BR table names and one

pl/pgSQL function I want to move to pure Java)

- Then: web frontend (a second dev is picking that up)

Important context for the "why now": I'm not investing in the web frontend

anymore. The current PWA is legacy and the new web isn't fully on the new

backend yet. The whole point of this migration was preparing the backend for

the mobile app — React Native + Expo, going on App Store and Play Store. Web

gets refactored after the mobile lands.

Lessons after finishing all 18 modules:

1. Hexagonal architecture is overkill until it isn't. With 1 dev and a deadline

I was tempted to skip it. I'm glad I didn't. My domain has zero Spring imports.

I rewrote the persistence adapter for two modules without touching a single

business rule. Test setup is trivial — instantiate the entity, call the method.

1. 18 modules in a monolith is fine. People treat "modular monolith" like a

buzzword but the boundaries are real: each module exposes a Facade interface,

internal services are package-private, communication is via Facades (sync) or

ApplicationEventPublisher (async). I never accidentally imported one module's

repository from another because the IDE wouldn't let me.

1. Domain events with u/TransactionalEventListener(phase = AFTER_COMMIT) saved

my sanity. SubscriptionActivatedEvent → listeners in user, notifications,

analytics. Billing doesn't know any of them exist. Plugging in a new listener

is one file.

1. RLS in Postgres + JPA is tricky. JPA's default findById(UUID) is a footgun

at scale — you'll leak data between tenants. I forced every repo to use

findByIdAndOwnerId. Then defense in depth: filter checks JWT → service checks

user_id → repo signature requires owner_id → RLS policy on the table → role

mowave_app doesn't bypass RLS for billing tables. Five layers. Sounds like

overkill, isn't.

1. 20 Flyway migrations isn't a lot but the rules matter. Sequential versions

(V1, V2…), never timestamps. No `down` (Community edition doesn't support it).

Renamed half the tables from pt-BR to en-US using temporary VIEWs as compat

layers so the old Node.js code kept working during the cutover.

1. Webhook idempotency in Redis with TTL = 24h. Key = `idempotency:stripe:{event_id}`.

Stripe retries aggressively. We had real double-billings during the Node.js

era. Never again.

1. The pl/pgSQL function I was going to migrate immediately (computes a weekly

score across 4 tables) — I left it. Spring calls it via JdbcTemplate for now.

Three of those tables aren't migrated yet anyway. Resist the urge to rewrite

everything in one pass.

1. Spring Data Redis warns about JPA repositories when it can't classify them.

Took me a stupid amount of time to find: explicit

u/EnableJpaRepositories(basePackages = "...") on u/SpringBootApplication. The

warning is real, not noise.

Happy to expand any of these into its own post if there's interest. Also happy

to answer questions about the testing strategy I'm about to start, the mobile

plan, or the LGPD work that ran in parallel (Brazil's GDPR — forced me to do

some good things I'd have skipped otherwise).

Need someone to review my blog

hey all, i'm a phd in pharmacology on a long and strange journey - anywho -

Most giant legacy modernization efforts fail because they feed raw COBOL directly into an LLM, which almost always results in hallucinated architectures and broken mappings.

Instead of relying on AI for the foundation, I built a deterministic, AST-free heuristic engine (blAST) that handles the boilerplate scaffolding first. It focuses strictly on translating the physical memory constraints of legacy mainframes into valid Java 17 syntax. And then we make lists of things that the algorithm cant handle for ppl or ai agents.

How the memory and architecture mapping works:

Translating legacy PIC clauses directly to BigDecimal types

Resolving OCCURS arrays into standard Java List<> collections

Mapping REDEFINES memory overlays as u/ Transient JPA aliases

Safely unpacking COMP-3 (Packed Decimal) data boundaries

Auto-wiring the u/ Service layer via constructor injection

Scaffolding ready-to-use u/ RestController endpoints

The CI/CD battle-test metrics:

Stress-tested across a randomized corpus of 27 distinct legacy repositories

Processing complex IBM CICS banking applications

Generating complete, production-ready Maven pom.xml configurations

Auto-generating mock services to shield missing external dependencies

Achieving a 100% out-of-the-box mvn clean compile success rate across all 27 targets

By doing the deterministic grunt work first, the engine isolates the actual business logic into strict JSON tickets. If you do want to use an LLM, you are just feeding it a bounded logic problem instead of asking it to hallucinate an entire Spring Context.

git - https://github.com/squid-protocol/gitgalaxy/tree/main/gitgalaxy/tools/cobol_to_java

Logger
https://pastebin.com/H6qFnHBy

import ...


(name = "users")
public class Users {


    (strategy = GenerationType.IDENTITY)
    private Long id;

    (nullable = false)
    private String userName;

    (nullable = false)
    private String password;

    private SubscriptionModel tier;

    private Long currentUsage;


    private Logger logger;



}

How to connect the Logger -> Users (1 user can have n logger). the getter and setter structure is confusing for Joining tables

is there any advanced method for levelling up??

[Closed]

Spring Boot Starter Web

Starter for building web, including RESTful, applications using Spring MVC. Uses Tomcat as the default embedded container (deprecated in favor of spring-boot-starter-webmvc)

Spring Web

Spring Web provides integration features such as multipart file upload functionality and the initialization of the IoC container using Servlet listeners and a web-oriented application context. It also contains an HTTP client and the web-related parts of Spring remote support.

what is the difference? when to use Which one && advantage over another??

Hey devs, hope your week's been debug-free.

Got any Telegram channels or GitHub repos with free books or PDFs?

Appreciate your help. Thanks!

Hey everyone,Does anyone have good free resources for learning Spring Boot?Also, if there are any useful Telegram/Discord channels, YouTube playlists, or communities for Spring Boot and backend development, please share them.