DEV Community

Karan Sahani
Karan Sahani

Posted on

⚡ I Got Tired of Writing the Same Spring Boot Code… So I Built a Generator Inside IntelliJ

⚡ I Got Tired of Writing the Same Spring Boot Code… So I Built a Generator Inside IntelliJ

Every Spring Boot project starts the same way.

You create an entity…
and then spend the next hour writing:

  • Repository
  • Service
  • Controller
  • DTOs
  • Mappers
  • Exception handling
  • Pagination

Nothing difficult.
Just repetitive.

And repetition is where productivity dies.

🤯 The Real Problem Nobody Talks About

It’s not about writing code.

It’s about rewriting the same code again and again:

  • Same patterns
  • Same structure
  • Same logic

And yet…

We still do it manually.


🧠 The Idea

I asked myself a simple question:

What if selecting a class could generate an entire backend layer?

Not boilerplate.
Not templates.

But production-ready code.


⚙️ Under the Hood (The Interesting Part)

Building this inside IntelliJ was way more complex than expected.

🔹 1. Reading Code Like IntelliJ Does (PSI)

You don’t parse Java files manually.

You work with IntelliJ’s PSI (Program Structure Interface):

  • Detect fields
  • Identify annotations like @Entity
  • Extract metadata

Without PSI → nothing works.


🔹 2. Generating Code That Doesn’t Look Generated

Most generators fail here.

They produce:

  • Ugly code
  • Poor structure
  • Hard to maintain

I wanted the opposite:

Code that feels like a senior developer wrote it.

That meant:

  • Clean layering (Controller → Service → Repository)
  • DTO separation
  • Proper naming conventions

🔹 3. Dependency Injection Without Breaking Projects

This turned out to be one of the hardest parts.

You need to:

  • Detect if dependency already exists
  • Support both Maven & Gradle
  • Avoid duplicates
  • Insert safely inside correct block

A naive approach breaks builds instantly.

So I built logic to:

  • Scan existing dependencies
  • Inject only when missing
  • Keep it idempotent

🔹 4. Optional Security (JWT)

Security isn’t just “add dependency”.

It involves:

  • Filters
  • Authentication flow
  • User + roles
  • Token handling

And it had to be:

Optional. Clean. Non-breaking.


🔹 5. Supporting Multiple Databases

Different teams → different databases.

So I added dynamic support for:

  • MySQL
  • PostgreSQL
  • MongoDB
  • H2

Challenge:

  • JPA vs Mongo are fundamentally different
  • Configurations vary
  • Drivers must be injected conditionally

⚡ The Biggest Lesson

Generating code is easy.
Generating safe, usable, production-ready code is hard.


🧩 What This Changed for Me

I stopped thinking like a developer writing code.

And started thinking like:

A developer building tools for developers.


🚀 Why This Matters

This isn’t just about saving time.

It’s about:

  • Reducing friction
  • Standardizing architecture
  • Eliminating repetitive mental load

Because energy should go into solving real problems…
not rewriting CRUD for the 50th time.

💬 Final Thought

The best tools don’t just automate tasks.

They remove unnecessary thinking.

If you’ve ever tried building developer tools,
or struggled with safe code generation…

I’d love to hear your approach 👇

Top comments (3)

Collapse
 
buildbasekit profile image
buildbasekit

This is solid. The PSI + safe dependency injection part is where most generators usually break.

One thing I’ve seen though, generating CRUD layers solves maybe 60–70% of the repetition.

The bigger friction starts right after:

  • auth setup (roles, permissions)
  • multi-tenancy
  • cross-cutting concerns across services

That part still ends up being rebuilt manually in every project.

Curious if you’ve thought about extending this beyond CRUD into those layers, or if you want to keep it focused on code generation only?

Collapse
 
karansahani78 profile image
Karan Sahani

Thanks a lot—really appreciate this insight.

You’re absolutely right that CRUD solves only part of the problem. That’s actually why I added JWT-based authentication with role-based access (USER / ADMIN / MODERATOR) in the generator—to cover at least the initial security setup.

But I agree, the bigger challenges come right after:

• permission-level control beyond roles
• multi-tenancy design
• cross-cutting concerns across services

Right now, my focus has been making the core foundation (CRUD + structure + security baseline) reliable and production-ready—especially ensuring PSI safety and clean dependency handling.

That said, I’m actively exploring extending this into:

  • modular add-ons (multi-tenancy, advanced security)
  • reusable cross-cutting layers
  • possibly more opinionated backend starter setups

The tricky part is going deeper without making the tool too rigid.

Curious from your experience—would you prefer something more modular and configurable, or a more opinionated full backend template?

Would love to hear your thoughts.

Collapse
 
karansahani78 profile image
Karan Sahani

If you're curious, I turned this into an IntelliJ plugin you can try here:
plugins.jetbrains.com/plugin/29476...

Would love your feedback 🙌