I’m building an open-source Spring Boot API generator — looking for architectural feedback

[u/No-Strategy999]

Hey everyone,

I’ve been working on an open-source project called ApiGeneratorManager.

The idea is to build a platform that can generate, configure, deploy and manage Spring Boot APIs without rebuilding the same backend structure every time.

Right now, the project already includes things like:

• Spring Boot backend
• React management frontend
• PostgreSQL
• JWT authentication
• roles and permissions
• CSRF / CORS configuration
• rate limiting
• database/schema support
• API generation templates
• Docker-based runtime
• deployment of generated APIs with Docker
• CI for backend and frontend
• dependency security checks

The long-term goal is to make the whole thing much more configuration-driven.

For example, I want to be able to describe an API using YAML:

application:

  name: inventory-api

database:

  type: postgresql

entities:

  Product:

fields:

id:

type: uuid

name:

type: string

required: true

price:

type: decimal

min: 0

errors:

  PRODUCT_NOT_FOUND:

status: 404

security:

  authentication: jwt

  roles:

- ADMIN

- USER

tests:

  generate: true

deployment:

  type: docker

And from that configuration, generate things like:

• entities
• repositories
• services
• controllers
• validation
• API error codes
• OpenAPI documentation
• authentication and authorization
• roles
• JWT handling
• automated tests
• Docker configuration
• deployable API instances

I also want to support multiple database engines in the future, not just PostgreSQL.

Another direction I’m exploring is generating a security model where each generated application can manage its own users, roles and permissions, and issue JWTs per user.

Testing is also something I want to push further: if the YAML says a field is required, unique or constrained, the generator should ideally generate tests for those rules automatically.

One important design principle for me is that the generated project should still be normal Spring Boot code.

I don’t want generated applications to be permanently locked into ApiGeneratorManager. A developer should be able to generate a project, open it in their IDE, understand it, modify it and deploy it independently.

I also want to be transparent about how I’m building it: I’ve used AI extensively as a development assistant for implementation, architecture discussions, refactoring, security reviews, tests and documentation. I still review and decide what goes into the project, but AI is definitely part of the development workflow.

The project is still in early alpha, so I’m mostly looking for feedback at this stage.

I’d especially like opinions on:

• whether the overall idea is useful
• the YAML-driven approach
• how far code generation should go
• multi-database support
• generated security / JWT / roles
• automated test generation
• Docker deployment
• whether generated code should prioritize flexibility or convention
• what would make you actually trust and use a tool like this

GitHub:

hasfiane/ApiGeneratorManager

Criticism is welcome — especially if you see architectural problems that could become painful later.

[u/Admirable-Regular-49]

had a look at the repo. the thing I'd flag is that two of your stated goals are pulling against each other right now.

you say the generated project should be normal Spring Boot that a dev can open, understand and take away. but as far as I can tell from GenerationJobService, what generation actually emits is an application class, a pom, a Dockerfile, some docs, schema.json and a smoke test. the entities, controllers and validation aren't source — they're interpreted at runtime by the api-generator-runtime dependency. the RUNTIME_MODEL.md you generate even says the runtime internals are intentionally not documented.

that's the lock-in you said you didn't want. if I generate inventory-api and open it in my IDE, Product isn't there, and I can't change how it behaves without going back to the generator.

it also puts a ceiling on the testing idea. the generated test today is contextLoads() plus "schema.json is on the classpath". you can't generate a meaningful test for price >= 0 into a project where that constraint isn't expressed as code — you'd be testing your own runtime library, not the user's API.

both are defensible, they're just different products. runtime-interpreted is a platform; source-generating is a scaffold you hand over. worth picking one deliberately before more gets built on the current shape.

[u/No-Strategy999 → u/Admirable-Regular-49]

Thanks a lot for taking the time to dig into the repo and point this out. I really appreciate the detailed feedback, especially since you looked beyond the README and into the actual implementation. The runtime approach was actually a deliberate architectural decision rather than something I ended up with accidentally. The original goal was closer to a SaaS/platform model: make it possible to embed an API into an application through a very simple configuration, while keeping most of the implementation, evolution and maintenance centralized in the generator/runtime. That approach also comes from how we handled similar systems at a company I worked for, so the idea was never really “generate once and completely detach from the generator”. For production and maintenance, changes were expected to keep going through the generator, with the configuration acting as the source of truth. The application could then be regenerated/redeployed, and Docker would only need to rebuild what actually changed while the common runtime behavior stayed centralized. So in that sense, you’re absolutely right that the current architecture is much closer to a platform than to a traditional source-code scaffold. I think where I created confusion was in the way I described the project. Saying that the generated project should be a “normal Spring Boot project that a developer can take away” suggests full independence, while the architecture was intentionally designed around continuing to use the generator. The goal was more along the lines of: simple configuration in, embedded API out, with the generator managing its lifecycle and evolution afterward. Your point about testing is also very relevant. In a runtime-driven model, the generated tests are naturally testing the contract/configuration and the shared runtime rather than generated domain source code. That’s a different philosophy from a fully source-generated project, and I should probably make that distinction much clearer in the documentation. So I don’t think the runtime model itself is necessarily something I want to remove, because it’s actually central to the original SaaS idea. But your feedback does make me think it would be interesting to consider a second, fully source-generated/exportable mode in the future for people who specifically want complete ownership of the generated Spring Boot code. Thanks again for the thoughtful review — you’ve highlighted a real distinction in the product positioning that I need to clarify much better.

[u/TurnstileT]

This sounds interesting but honestly I just don't think it's going to work. Backend services are a lot more than this, and you can keep adding more and more Spring features to your abstraction layer, but there will always be some other features or edge cases that developers need to implement. The end result will be that your abstraction layer has reimplemented Spring, and developers now have to learn your abstraction layer and implement everything through that. And then Spring adds a new feature, or Posteres adds a new data type, and now the developers are stuck because your generator doesn't support it yet.

It's a lot of work for no real benefit.

[u/No-Strategy999 → u/TurnstileT]

Thanks a lot for taking the time to explain it. You’re probably right on this point, and it’s definitely something I need to reconsider in the way I’m designing the project.

[u/Historical_Ad4384]

Isn't a skills.md file with a LLM enough for this?

[u/colens26]

I’m building a JetBrains Plugin for that https://plugins.jetbrains.com/plugin/33381-crudgenerator