5 ms·

> Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application. It sounds good but in reality

> Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application. It sounds good but in reality people end up spending time messing around with config files and annotations.

gf000 2y ago
Like, what other option is there? There is either a proper, battle-tested solution which requires some configuration so that it works as you want, or you start from scratch and create something specifically for your own usecase. In the latter case, it may actually mean a significant amount of development orders of magnitude more than looking up how to configure stuff, constant maintainance, etc.
- whstl 2y ago
  > Like, what other option is there? For this specific case there's plenty... You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little. You can use other frameworks that also have those features, in Java or in other languages. You can use a paid authentication services. You can use an open source authentication services.
  - gf000 2y ago
    I was talking more abstractly, in that understanding a given feature to be able to configure it properly is not optional (besides asking someone else to handle some part of the complexity e.g. third party authentication services in this case).
    - deleted 2y ago
      [deleted]
    - whstl 2y ago
      But in none of those you "end up spending time messing around with config files and annotations", which was the problem mentioned by the grandparent. So yes: there are other options.
  - okeuro49 2y ago
    > You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little. Then you have to work to make the libraries all work together. And deal with updates. Spring Boot allows to to update all libraries together, and know that they work together.
    - whstl 2y ago
      For this you setup tests and a CI, which is basic stuff that you can't really skip with Spring. If you don't want or know how to do this, then there are all the other solutions. Either way: authentication in a Spring app is the definition of "reinventing the wheel".
- lenkite 2y ago
  In Go, people will write code to use the standard library for the app they are developing instead of pulling in a framework to do the work for them. Most Go developers have a culture of minimizing dependencies to utterly essential ones that they cannot write on their own. In Java, people will pull in a 100MB+ mega-framework for a hello-world REST service. Oh and another 50MB for ORM. Another 25MB+ for nailpolish, etc. The extreme difference in basic developer culture causes visible differences in performance outcomes. Can't even blame the JVM - it is a superb beast that is overloaded by Java developers putting Mount Everest atop it.
  - okeuro49 2y ago
    > In Java, people will pull in a 300MB+ mega-framework for a hello-world REST service. Oh and another 200MB for ORM. Another 250MB+ for nailpolish, etc. I just now used https://start.spring.io/ https://start.spring.io/ to generate a project using Spring web, Spring security and Spring data JPA (Hibernate). It generated a JAR that is 52MB.
    - lenkite 2y ago
      Thanks - I haven't used the Spring Generator for several years now. However, I think one also needs to include the drivers, oauth stuff, template libraries, etc to get an accurate represention of "standard Java enterprise size". Gonna play with this offline and see how good it has got.
      - gf000 2y ago
        You might want to check the native spring native plugin as well, which can AOT compile the whole thing to a single binary (thanks to Graal).
      - ivan_gammel 2y ago
        A real monolithic app dealing with videostreaming that I have been working recently, was based on Spring Boot and AWS SDK and it was a 82 Mb jar file. It had the drivers, oauth stuff, a couple of template engines for business reasons (Handlebars and Thymeleaf), database and queue drivers etc. It could be maintained and extended by a junior developer, because it had established design patterns and they only needed to follow some project conventions. We had multiple releases per week at engineering cost of less than 25k€ per year. I would not be able to build something like that with that budget on Go.
mike_hearn 2y ago
Maybe? Depends on the framework. I've been using some Micronaut lately and it's a Spring-inspired framework where a lot of stuff Spring does at runtime is done up front at compile time. The result is apps start really fast, can be compiled to a standalone native binary with GraalVM, use little memory, and errors that would once have resulted in a complex exception at startup now yield reasonable compiler errors instead (it has compiler plugins to make this work well). I can't say I've spent much time messing with annotations or config files in this project. Certainly, what little time has been spent on the framework is more than saved by what it does.
javanonymous 2y ago
> It sounds good but in reality people end up spending time messing around with config files and annotations. I use Spring Boot at my day job and write mostly web services. I don't spend time messing around with config files and annotations. When I create a service class, I annotate it with @Service, and that is mostly what I need. Example: @Service public record ItemsService(ItemsRepository repo) { public void doStuff(String country) { var items = repo.findByCountry(country); // do stuff with items } } Later versions of Spring Boot has reduced a lot of the annotations necessary, like @Inject if you use constructors etc. There are of course other annotations and configurations, but 90% of what I do is similar to the example I gave above. Things may have changed since last you used it, but the amount of "magic" and annotations is often much less than what is posted in these types of discussions.

gf000 2y ago

Like, what other option is there? There is either a proper, battle-tested solution which requires some configuration so that it works as you want, or you start from scratch and create something specifically for your own usecase. In the latter case, it may actually mean a significant amount of development orders of magnitude more than looking up how to configure stuff, constant maintainance, etc.

whstl 2y ago
> Like, what other option is there? For this specific case there's plenty... You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little. You can use other frameworks that also have those features, in Java or in other languages. You can use a paid authentication services. You can use an open source authentication services.
- gf000 2y ago
  I was talking more abstractly, in that understanding a given feature to be able to configure it properly is not optional (besides asking someone else to handle some part of the complexity e.g. third party authentication services in this case).
  - deleted 2y ago
    [deleted]
  - whstl 2y ago
    But in none of those you "end up spending time messing around with config files and annotations", which was the problem mentioned by the grandparent. So yes: there are other options.
- okeuro49 2y ago
  > You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little. Then you have to work to make the libraries all work together. And deal with updates. Spring Boot allows to to update all libraries together, and know that they work together.
  - whstl 2y ago
    For this you setup tests and a CI, which is basic stuff that you can't really skip with Spring. If you don't want or know how to do this, then there are all the other solutions. Either way: authentication in a Spring app is the definition of "reinventing the wheel".
lenkite 2y ago
In Go, people will write code to use the standard library for the app they are developing instead of pulling in a framework to do the work for them. Most Go developers have a culture of minimizing dependencies to utterly essential ones that they cannot write on their own. In Java, people will pull in a 100MB+ mega-framework for a hello-world REST service. Oh and another 50MB for ORM. Another 25MB+ for nailpolish, etc. The extreme difference in basic developer culture causes visible differences in performance outcomes. Can't even blame the JVM - it is a superb beast that is overloaded by Java developers putting Mount Everest atop it.
- okeuro49 2y ago
  > In Java, people will pull in a 300MB+ mega-framework for a hello-world REST service. Oh and another 200MB for ORM. Another 250MB+ for nailpolish, etc. I just now used https://start.spring.io/ https://start.spring.io/ to generate a project using Spring web, Spring security and Spring data JPA (Hibernate). It generated a JAR that is 52MB.
  - lenkite 2y ago
    Thanks - I haven't used the Spring Generator for several years now. However, I think one also needs to include the drivers, oauth stuff, template libraries, etc to get an accurate represention of "standard Java enterprise size". Gonna play with this offline and see how good it has got.
    - gf000 2y ago
      You might want to check the native spring native plugin as well, which can AOT compile the whole thing to a single binary (thanks to Graal).
    - ivan_gammel 2y ago
      A real monolithic app dealing with videostreaming that I have been working recently, was based on Spring Boot and AWS SDK and it was a 82 Mb jar file. It had the drivers, oauth stuff, a couple of template engines for business reasons (Handlebars and Thymeleaf), database and queue drivers etc. It could be maintained and extended by a junior developer, because it had established design patterns and they only needed to follow some project conventions. We had multiple releases per week at engineering cost of less than 25k€ per year. I would not be able to build something like that with that budget on Go.

mike_hearn 2y ago

Maybe? Depends on the framework. I've been using some Micronaut lately and it's a Spring-inspired framework where a lot of stuff Spring does at runtime is done up front at compile time. The result is apps start really fast, can be compiled to a standalone native binary with GraalVM, use little memory, and errors that would once have resulted in a complex exception at startup now yield reasonable compiler errors instead (it has compiler plugins to make this work well). I can't say I've spent much time messing with annotations or config files in this project. Certainly, what little time has been spent on the framework is more than saved by what it does.

javanonymous 2y ago

> It sounds good but in reality people end up spending time messing around with config files and annotations. I use Spring Boot at my day job and write mostly web services. I don't spend time messing around with config files and annotations. When I create a service class, I annotate it with @Service, and that is mostly what I need. Example: @Service public record ItemsService(ItemsRepository repo) { public void doStuff(String country) { var items = repo.findByCountry(country); // do stuff with items } } Later versions of Spring Boot has reduced a lot of the annotations necessary, like @Inject if you use constructors etc. There are of course other annotations and configurations, but 90% of what I do is similar to the example I gave above. Things may have changed since last you used it, but the amount of "magic" and annotations is often much less than what is posted in these types of discussions.