6 ms·

> In a team with 100 devs, simplifying and unifying decisions is extremely important. I agree with this. Unfortunately, Spring is often chosen for projects wi

> In a team with 100 devs, simplifying and unifying decisions is extremely important. I agree with this. Unfortunately, Spring is often chosen for projects with much smaller teams too. Just 1 to 5 devs on what is fundamentally just a CRUD app. Wrong tool for the job.

oweiler 6y ago
I disagree. I can spin up a CRUD service with Spring Boot in an hour including validation, health checks, db migrations, API documentation and what not. It lets me move fast while taking care of the boring stuff. Nothing to do with team size.
- eecc 6y ago
  That’s all fine and nice, except when the magik doesn’t work and you’re ctrl-clicking for hours trying to figure out what darn annotation is breaking the whole incantation. Or you realize a that the tiny tiny small configuration change you need isn’t contemplated by the code supporting the auto-magik, so you start adding overrides which turn off the autoconf, and you have to manually configure the whole beast by yourself (discovering all the undocumented gotcha’s along the way.)
  - soco 6y ago
    Luckily this doesn't happen all that often. Unfortunately this is gonna happen in every framework. Compromises is what you always get when reusing somebody else's framework/program/anything basically, because use cases are never 100% similar.
    - eecc 6y ago
      Well, as someone else on this thread wrote, it does happen all the times you're not preparing for a presentation or a blog. If you're building something marginally different from the routine the curtain is drawn, and IMHO you're probably better off buying a shrink-wrapped ready-made SAAS.
    - lmm 6y ago
      A good framework lets you gracefully progress from 100% autoconfigured to 95% autoconfigured, 5% customized to 90% autoconfigured, and so on. It does this by working in a consistent way, where framework-provided defaults behave the same as custom implementations of the same thing, and you can use the same tools and techniques to understand what the framework is doing as you use to understand your own application. None of that's true of Spring Boot. The autoconfigured stuff comes in in its own fashion that's hard to relate to your normal configurations, and it's encapsulated in such a way that as soon as you want to replace part of it you find you have to reimplement all of it.
- qw 6y ago
  I have the same experience as you. I have used Spring Boot in different environments for 5-6 years (first complex global enterprise and later small startup). Spring Boot have been enabling me to be very productive. I haven't had any major issues that I can blame on the "magic" that Spring Boot provides. I have read startup experiences with other frameworks where they write blog posts about all the issues they had to spend time to fix, that is trivial to solve using Spring. There is a slight learning curve in the beginning, but it is worth it in my opinion.
- selfhoster11 6y ago
  You know what should be taking care of all of these things? Java! For a language that bills itself as the "enterprise language #1", it's abysmal in supporting actual enterprise features like you listed above in a lightweight fashion. Instead, a whole third-party framework has to be tacked on just so you don't have to reinvent the wheel. Java doesn't even support dependency injection, something that I would consider an absolute minimum for even a small project.
  - diroussel 6y ago
    The real thing that is missing is a runtime annotation scanning API. Spring does this my examining the class path, casting it to a urlclasspath, finding all the zip/jar files, unzipping them and then parsing the byte code. Interestingly the set let spec added annotation scanning too. And now if your not careful you jar files get extracted three times. The JVM, the server conteainer and spring all repeating the same work. No wonder people think java is slow to start up.
  - dmux 6y ago
    >Java doesn't even support dependency injection, something that I would consider an absolute minimum for even a small project. For small projects, DI is easy done by passing things via the constructor. If multiple things need to get wired together, pull that wiring logic out into its own class or method (FooBuilder.buildDefault()). If things start to get tedious, that's a really good time to stop and reflect on the design choices. That stop-and-reflect opportunity if often lost when things can be simply AutoWired together.
  - jacques_chester 6y ago
    Jakarta (née Java EE) has CDI, which bears a striking similarity to the Spring's dependency injection capability: http://cdi-spec.org/ http://cdi-spec.org/
  - cryptos 6y ago
    I don't think there is a need to blur the line between a standard library and frameworks. Maybe @Inject should have been in the JDK, but on the other hand it can be added to any project easily and is supported by several frameworks. In general I think, it is wise to keep the standard library small, because innovations are easier to implement in libraries. Rust is a good example for this style.
- matwood 6y ago
  Same. Spring boot + jooq is a quick, simple way to spin up backend services. Like any tool though, one needs to know Spring boot.

oweiler 6y ago

I disagree. I can spin up a CRUD service with Spring Boot in an hour including validation, health checks, db migrations, API documentation and what not. It lets me move fast while taking care of the boring stuff. Nothing to do with team size.

eecc 6y ago
That’s all fine and nice, except when the magik doesn’t work and you’re ctrl-clicking for hours trying to figure out what darn annotation is breaking the whole incantation. Or you realize a that the tiny tiny small configuration change you need isn’t contemplated by the code supporting the auto-magik, so you start adding overrides which turn off the autoconf, and you have to manually configure the whole beast by yourself (discovering all the undocumented gotcha’s along the way.)
- soco 6y ago
  Luckily this doesn't happen all that often. Unfortunately this is gonna happen in every framework. Compromises is what you always get when reusing somebody else's framework/program/anything basically, because use cases are never 100% similar.
  - eecc 6y ago
    Well, as someone else on this thread wrote, it does happen all the times you're not preparing for a presentation or a blog. If you're building something marginally different from the routine the curtain is drawn, and IMHO you're probably better off buying a shrink-wrapped ready-made SAAS.
  - lmm 6y ago
    A good framework lets you gracefully progress from 100% autoconfigured to 95% autoconfigured, 5% customized to 90% autoconfigured, and so on. It does this by working in a consistent way, where framework-provided defaults behave the same as custom implementations of the same thing, and you can use the same tools and techniques to understand what the framework is doing as you use to understand your own application. None of that's true of Spring Boot. The autoconfigured stuff comes in in its own fashion that's hard to relate to your normal configurations, and it's encapsulated in such a way that as soon as you want to replace part of it you find you have to reimplement all of it.
qw 6y ago
I have the same experience as you. I have used Spring Boot in different environments for 5-6 years (first complex global enterprise and later small startup). Spring Boot have been enabling me to be very productive. I haven't had any major issues that I can blame on the "magic" that Spring Boot provides. I have read startup experiences with other frameworks where they write blog posts about all the issues they had to spend time to fix, that is trivial to solve using Spring. There is a slight learning curve in the beginning, but it is worth it in my opinion.
selfhoster11 6y ago
You know what should be taking care of all of these things? Java! For a language that bills itself as the "enterprise language #1", it's abysmal in supporting actual enterprise features like you listed above in a lightweight fashion. Instead, a whole third-party framework has to be tacked on just so you don't have to reinvent the wheel. Java doesn't even support dependency injection, something that I would consider an absolute minimum for even a small project.
- diroussel 6y ago
  The real thing that is missing is a runtime annotation scanning API. Spring does this my examining the class path, casting it to a urlclasspath, finding all the zip/jar files, unzipping them and then parsing the byte code. Interestingly the set let spec added annotation scanning too. And now if your not careful you jar files get extracted three times. The JVM, the server conteainer and spring all repeating the same work. No wonder people think java is slow to start up.
- dmux 6y ago
  >Java doesn't even support dependency injection, something that I would consider an absolute minimum for even a small project. For small projects, DI is easy done by passing things via the constructor. If multiple things need to get wired together, pull that wiring logic out into its own class or method (FooBuilder.buildDefault()). If things start to get tedious, that's a really good time to stop and reflect on the design choices. That stop-and-reflect opportunity if often lost when things can be simply AutoWired together.
- jacques_chester 6y ago
  Jakarta (née Java EE) has CDI, which bears a striking similarity to the Spring's dependency injection capability: http://cdi-spec.org/ http://cdi-spec.org/
- cryptos 6y ago
  I don't think there is a need to blur the line between a standard library and frameworks. Maybe @Inject should have been in the JDK, but on the other hand it can be added to any project easily and is supported by several frameworks. In general I think, it is wise to keep the standard library small, because innovations are easier to implement in libraries. Rust is a good example for this style.
matwood 6y ago
Same. Spring boot + jooq is a quick, simple way to spin up backend services. Like any tool though, one needs to know Spring boot.