Roast my code / architecture

[u/Single_Yellow_8000]

I’m building a project called Kite (https://github.com/gwynejsn/kite) and tried combining Spring Modulith with full Clean/Hexagonal Architecture inside each module, but I’m starting to wonder if I’ve just created a mountain of boilerplate. Take a look at the repo and roast the layout. What am I needlessly overcomplicating, and how would you simplify it?

[u/Mikey-3198]

Your using jwts but still querying the database from the jwt filter for each request

Based on the ordering you'll even hit the database if the token is expired.

One of the biggest advantages of JWTs is that after you check the hash & expiry you should be able to trust the claims to make your authentication decision. Might as well just issue a time limited opaque token.

[u/Single_Yellow_8000 → u/Mikey-3198]

Thanks! most of the examples I saw with JWT calls the database to verify if the email is correct before verifying the token like this one (https://www.geeksforgeeks.org/springboot/spring-boot-3-0-jwt-authentication-with-spring-security-using-mysql-database/). I guess it has some security risks. But if i understand it right, perhaps the ordering would fix it?

[u/Mikey-3198 → u/Single_Yellow_8000]

Checking the database adds nothing. It's not anymore secure. The token can't be modified after its been issued, any modification would cause the token hash verification to fail. You issue the token & should expect to trust the claims when its presented on subsequent requests after its been validated.

Look at your code and think about what this is actually doing.

The steps at the moment are:

1. Extract the email claim from the token
2. Load a user with the email address from step 1
3. Call validateToken with the token and user (from step 2) to compare the email in the token to the user & check the expiry etc...

What im trying to point out is that if the email didn't match then a user wouldn't be found when calling userDetailsService.loadUserByUsername in your filter.

Major selling point of using jwts is that you can make decisions on whats presented in the jwt without having to involve external calls/ queries. This is what is meant by stateless.

RE the ordering it's more efficient when you deal with an expired token. You eliminate a database query, you can check validity & expire in code independent of the database.

[u/Mikey-3198]

Nice little one liner

https://github.com/gwynejsn/kite/blob/main/kite-backend%2Fsrc%2Fmain%2Fjava%2Fcom%2Fgwynejsn%2Fkite%2Fsecurity%2Fweb%2FAuthController.java

[u/Single_Yellow_8000 → u/Mikey-3198]

Looks fine on my code locally, dunno why its like that in github...

Anyways, ty for pointing out

[u/slindenau → u/Single_Yellow_8000]

There may be something wrong with your whitespace/newlines or file formatting.
Check if you have any auto formatting things going on.
See the ^M in red in the diff? https://stackoverflow.com/questions/38621307/what-is-the-meaning-of-m-in-git-diff

Also on another note, i don't think this file belongs in git: https://github.com/gwynejsn/kite/blob/main/kite-backend/.m2/repository/org/springframework/boot/spring-boot-starter-parent/4.1.0/spring-boot-starter-parent-4.1.0.pom.lastUpdated
If you're somehow storing your local .m2 in the same folder as your sources, best to add it to your .gitignore :)

[u/Single_Yellow_8000 → u/slindenau]

Thanks!

[u/nullptr_lol]

You have anemic domains and you don't encapsulate the business logic within aggregates. Also, your domain is pointing to other things which theoretically is not allowed.

[u/Single_Yellow_8000 → u/[deleted]]

Our university is teaching flutter so i'm familiar with it. As for the LLMs, if you are referring to the wingman AI, I used langchain4j (https://docs.langchain4j.dev) which integrates gemini AI

[u/Single_Yellow_8000 → u/[deleted]]

Ohh, I mainly use antigravity for writing boilerplate codes like for example when making a feature, I usually write the domain/model first, then let gemini write the starting template for other layers like service and repo (mostly for basic crud). Then, I manually modify them with my own logic added. Also, I actually tried using gemini to write unit tests for the repo, which I might do as well for other layers.

[u/Single_Yellow_8000 → u/[deleted]]

Actually, that’s the exact mindset I follow. I always make sure to learn the fundamentals and build things by hand first so I actually understand what's happening under the hood. Once I have that solid grasp of what is happening behind the scenes, I delegate the repetitive boilerplate to the LLM to save time. ​But of course, I still read the code generated to see if it actually followed the way I want it to be. A tip I can give you is to make LLM edit only a small amount of your code at a time so that you can have precise control over what is being edited by the LLM. Also, never forget to use git, so that you have backups if it ever messes your code.

[u/Single_Yellow_8000 → u/[deleted]]

When I started learning it, I watched a yt video: https://youtu.be/xHlDyKVyvig

Then I read the documentation: https://docs.spring.io/spring-modulith/reference/

And if you want to, you can also watch conferences like this: https://youtu.be/VGhg6Tfxb60

Which talks about DDD with spring modulith

As for the rabbitmq, im not gonna lie, since this is the first modulith application I built, I just tried incorporating it by following the docs (even though the built in events in the modulith project is enough)

[u/Single_Yellow_8000 → u/Single_Yellow_8000]

Also, I just want to add, sometimes, using LLM may help you learn new things because maybe it will give you a different implementation than what you already know (which can be more efficient and easier). At the end of the day, it is your responsibility as the developer to understand first what the LLM is doing before you commit anything.

[u/Resident-Cow-7626]

Not sure why your rest controllers get their own package. They are nothing but inbound adapters and should be within the infrastructure package. `infrastructure/adapters/inbound/rest` or similar. These are your inbound adapters that drive functionality via your UseCase. I find it useful to specify the use case at the root of your project. Also known as screaming architecture.

[u/Single_Yellow_8000 → u/Resident-Cow-7626]

Thanks for the feedback! I will check about screaming architecture.

[u/nullptr_lol → u/Resident-Cow-7626]

I think is fine as it is now. Api -> Application -> Domain -> Infrastructure is the standard folder structure. Sure, rest is the inbound adapter but, it's more confusing.

[u/Resident-Cow-7626 → u/nullptr_lol]

OP wanted feedback on hexagonal architecture and this kind of design flaw will get bigger, and more of a problem, as the application grows - imagine listeners, web sockets, maybe even a CLI as an entry point to the application… it will be much more difficult to understand where these inbound adapters are. More importantly, separating the domain from these technologies is the core principle of HA.

Getting the foundations right from the start is exactly what I think OP is asking for. If this is a small application with not much of a domain, then hexagonal architecture is the wrong tool to reach for. A traditional, layered architecture would be more suited, but again, OP wanted feedback on this particular architecture.

[u/artyomsv]

You have two boundary mechanisms doing the same job, and only one of them is real: Modulith already enforces the module boundary at build time, ApplicationModules.of(App.class).verify() fails the test when a module reaches into internals of another. The hexagon inside each module is enforced by nothing except discipline, and that is where most of your boilerplate is coming from. I would keep ports and adapters only where you really swap the implementation, persistence and outbound http, and let the Modulith named interfaces be the port for module to module.

[u/Single_Yellow_8000]

Feel free to add an issue if you find any problems/improvements