3 ms·

Spring boot with Lombok has been my go to framework for a few years now. Annotation-based programming seems to get a lot of negative attention here on HN, and i

Spring boot with Lombok has been my go to framework for a few years now. Annotation-based programming seems to get a lot of negative attention here on HN, and it definitely is not perfect but there is just no other framework that (in my opinion) comes close in terms of productivity and workflow. Currently I'm building my SaaS + Selfhosted software licensing product with this Spring Boot + Lombok + Postgresql combo and Annotations are helping me out for : * @Bean, @Autowired, @Profile,... for configuring dependency injection with multiple profiles (saas vs selfhosted) * @Entity, @Table, @Repository, @Enumerated, @Embedded for mapping my classes to Database tables * @Api, @ApiOperation, @ApiParam,... for generating Swagger documentation for my endpoints * @GetMapping, @PostMapping, @PreAuthorize for configuring and authorizing my endpoints * Lombok @Data, @Value, @Builder for tedious boilerplate generation * @NotNull, @NotBlank, @Email, @PhoneNumber, @Pattern(regex), @Length(max=12),... for validation of form input, api params and database models. * @JsonProperty, @JsonSerialize, @JsonIgnore for configuring json deserializing for my DTO's * @Value("${my.config.key}") for decoupling configuration from my code and injecting values at runtime I probably forgot a few more use cases. All of these are pretty straightforward, are defined alongside the code they are modifying or interacting with and would lead me to a lot of lost time and a lot more code if I were to implement them myself, or configure them by hand "in real java code".

raz32dust 8y ago
While it is great while you are trying to get your product to market quickly, I would highly recommend getting rid of all these annotations as soon as you can. Preferably before your team grows to 5+ people or complexity grows beyond around 100k lines of code. It's hard to explain this to people from non-Java background, but the time writing non-annotation code will save you in debugging and maintainability is well worth it beyond that point.
- vbsteven 8y ago
  I can see that the dependency injection annotations can be complex for people not experienced with the whole Spring/IoC/DI setup. I have some rules and general guidelines I use for keeping them in check which I can explain in about 10minutes (and have done to team members in a few companies) Honestly, I prefer to debug with annotations and a debugger over a manually coded configuration class with hundreds of lines of wiring components together. And for removing the other annotations: Why should I decouple apidocs from my code? They are litterally annotating the source code so it makes sense to have them close. Stuff like the validators and JSON properties and configuration also makes sense to have them close to the fields that they are about instead of in a separate JsonSerializer class or whatever.

raz32dust 8y ago

While it is great while you are trying to get your product to market quickly, I would highly recommend getting rid of all these annotations as soon as you can. Preferably before your team grows to 5+ people or complexity grows beyond around 100k lines of code. It's hard to explain this to people from non-Java background, but the time writing non-annotation code will save you in debugging and maintainability is well worth it beyond that point.

vbsteven 8y ago
I can see that the dependency injection annotations can be complex for people not experienced with the whole Spring/IoC/DI setup. I have some rules and general guidelines I use for keeping them in check which I can explain in about 10minutes (and have done to team members in a few companies) Honestly, I prefer to debug with annotations and a debugger over a manually coded configuration class with hundreds of lines of wiring components together. And for removing the other annotations: Why should I decouple apidocs from my code? They are litterally annotating the source code so it makes sense to have them close. Stuff like the validators and JSON properties and configuration also makes sense to have them close to the fields that they are about instead of in a separate JsonSerializer class or whatever.