Just pinning a comment to address common feedback: 1. Skill Issue - Yeah, I actually agree. If I was perfect and never made mistakes I don't think things like magic would be a problem. But I do make mistakes, and I do have skill issues. This is actually why I favour simple technologies. I don't want to blow my leg off when I inevitably shoot myself in the foot. 2. Alternatives? - Ktor for Kotlin, Javalin for Java, pretty much any the Go web frameworks are good. The most popular web framework is usually a good option for most other languages
not trusting big framework is pretty good. but we gotta understand why python got so big in the market despite of its awful processing efficiency. but, spring security can kiss my ass.
Skill issue is when you can't do something without a framework or a scripting language. Try to do the same functionality in C. I can, cause i know the inner working of the computer and have principles in networking, as well as protocols adopted. High level scriptinmg and frameworks will help you go fast but you'll learn nothing. I'll stick to programming, much more a manly thing to do.
Hello, minor Spring Contributor and Java Developer here o/ I'll cover a general misconception, and then dig into some incorrect points here. You're perfectly fine to bring up these points, and it doesn't mean your grievances aren't valid per-say. Simply want to provide some better understanding of the situation. Note that I'll use Java EE/Java for what is now Jakarta EE/Jakarta, as Oracle gave the rights to the Open Source side of Java. Spring is best viewed as an adapter layer to other standards or libraries. Many of the issues brought up are either due to underlying standards (JPA/Hibernate, Java Servlets, etc), or a misunderstanding of the history of Java, specifically Java EE. Yes Spring relies heavily on "annotation magic", but that's because it's trying to expose a single entry point to many standards. For example the "@Transactional" can hook into many Transactional managers, meaning regardless of the underlying DB, you don't need to write custom code for a simple transaction. This means you get the same problem you get in any type of adapter approach, being that once behavior has to be customized, you either need the adapter to change (Spring does a good job of this), or bypassed (Far more common of developers to do this). Many issues I've seen with Spring code are Developers not knowing, and by extension misusing, the framework. I believe my explanation of an adapter covers 1:23, however I'll also plug in that Spring didn't invent annotations. This approach has been part of the official Java "standard" since as far back as 2005 (See JSR-181), and Spring even provides a more Functional Approach, docs.spring.io/spring-framework/reference/web/webmvc-functional.html 1:46, this is more a result of Java Servlet Filters, the flow of an HTTP Request/Response is well defined in the spec, jakarta.ee/specifications/servlet/6.1/jakarta-servlet-spec-6.1.pdf 2:24 mentioned with JSR-181, this is actually incredibly normal in the world of Java, and has exists for decades. 2:38 Developers don't have a strong understanding of HTTP. They have a strong understanding of the structure of the request/response. The moment you start asking questions like the usage of the X prefix, the reason to upgrade from HTTP 1.1 -> HTTP.2, etc, most developers will fall apart. This is totally normal and fine, but it means from a framework perspective you mostly care about how to expose the structure, and Spring has pages of documentation on how it does that. 3:18 , if you want full access, just use `public ResponseEntity myFunction(RequestEntity
Really good answer. Maybe should be pinned. Spring is a framework built on top of Java the language and Java the tooling infrastructure. All it's weirdness is coming from that context. That being said, it not having a defacto-standard query builder to circumvent JPA is the only thing that is really annoying me. Hibernate being default for persistence is just giving haters ammunition. Something simple for typesafe sql query building that builds on top of composition and fluid builder patterns would be awesome. But I guess Spring thinks itself really more like an adapter, therefore no custom impls for that stuff. Sad.
You see, but all of this would require him to learn the framework, but seems like it's too much work for him, so instead he prefers to reinvent the wheel and standards, obviously because his boss doesn't pay him to do so 🤷♂️ And off course, never forget, Spring is the worst. And how does he know that? Because he doesn't want to learn it!!! 🤦♂️
They went from garbage to still not good. I'm no fan of .NET by any means but it makes more sense to compare ASP with Spring & they just got many things right. Even in the strict OOP Space there are way better solutions. TAnd I'm pretty sure ther are better things in the JVM space as well.
There are so many misconceptions in this video, that it's really hard to even start with one. for example: "your domain model isn't guaranteed to be identical to your database one either (which is correct), this is a bold assumption that spring makes" - thats simply wrong. spring does not make this assumption at all, nothing is stopping you from going fully hexagonal and completely decouple your entities from your business and services models. spring does not even force you to use JPA or hibernate either. If you would want, you could write raw queries and execute them via a plain jdbc connection.
I've had to do that. We spent the better part of 3 months rewriting it to use the company standard (Spring Boot). The guy who initially wrote it created his own system for everything and documented nothing. It was hell.
I used Spring Security in Grails back in the 2.x and 3.x days... It was actually kind of cool as the Spring Security Plugin handled all the nastyness for us.
I feel this way, but about Hibernate instead. Absolutely the worst abstraction layer I’ve used in my life. It was a terrible decision to ever make, from top to bottom.
Magic doesn't exist. I despise all the high-level frameworks/tools that try to do everything for you, it literally *takes away* my ability to understand the program and program. I'm here because I'm looking to save time, not because I don't know how to do something. Unreal Engine, web dev frameworks and libraries, even broadcasting in numpy/PyTorch etc. . I will take extra boilerplate if it means that I know what to expect and that things are intuitive. If you're going to make abstractions, make them crisp. I'm a producer not a consumer. Thanks for coming to my TedTalk, I don't know where else to vent about it with people who may be somewhat like-minded lol
This is why I quit java development. When something went wrong it always was like 4 abstraction layers down, in a class I have never seen or interacted with, that is interacting with a bunch of other classes that I also have never seen or interacted with.
This is why I gave up coding in Java, then C++, C, Assembly and binary to code using transistors, I am jumping in now into electron spin microcode which is zero-overhead abstraction and the documentation is consistent across the known Universe.
@@BossFlight nah fam it's not an abstraction issue but an "unreliable abstraction" issue, which was much worse on java-based frameworks than C# or Go or even Python at the time. If you abstract things the framework should be solid like rock, I should not be required to go in and troubleshoot the framework of your framework or the core java classes because something broke at some level.
@@marcogenovesi8570 I have a friend who is really good at Java and also really likes it and I don't know how. I end up depth-first searching everything which can work in some limited ways but with a bloated system in a bloated language doesn't go well. I can't hold everything in my working memory and it feels like people who're good with it just pull constructs out of thin air in their mind and are somehow able to work with them. I think I have really good pattern recognition but limited working memory so for systems built on patterns (and, meaningful ones) I can work really well with them but for ones with a lot of arbitrary design decisions I just can't. I've tried really hard
@@BossFlight LOL it's true and I take the point, I guess what I meant by magic doesn't exist is that we have a limited number of patterns at our disposal before they essentially become arbitrarily mixing and matching/become obsolete and just bloat things. I do agree though and I think sometimes my bias in the other direction (i.e. toward doing everything explicitly) hinders more than it helps. Balance is hard and there's not a perfect answer to anything really
When Spring Boot was first being rolled out, it was being marketed as a rapid prototyping tool. In fact, the company I worked at saw it as a toy. We favored the non-boot XML-driven config BECAUSE it was way more clear what was going on. I think the issue is that the industry has moved on to using Boot as a production standard.
Speaking of Boot in production, the actuator is really quite useful. As far as keeping config understandable, the annotations work as well or better than XML once you get used to them. The key is to be consistent and logical. Also, tooling such as STS and IDEA can be a great help.
first time using spring: "woah this is so cool I don't have to write queries anymore" six months into spring: "why tf it's expecting a long, I defined it as byte[]/bytea" (I still don't know why, I just know writing the query myself solved it)
this is the reason I love Go so much. I have a background with Spring and Aspnet Core. Most of the time I am stuck reading the documentation to understand how magic works just for simple modification from the happy path.
Controversival Take: Don't use something you don't understand. Spring's Documentation is actually fairly easy to understand. Of course it can be big in size, but that entirely depends on the Spring modules you bundle and use within your application. Spring Boot will autoconfigure the basic standard for you (depending on the module you might have to configure a base yourself, but again Documentation!). The moment you deviate from that standard of course you have to dig in to documentation and implement it yourself. In fact, you can reconfigure most partial components Spring uses by providing an implementation for yourself. And also you don't have to even use every Spring module under the sun. Want to write your own Security module? Go ducking do it, you just need to integrate it with Spring Web or whatever you need. Don't want to use Spring Web, then write your own Code to instantiate a Web-Server and define routes and create interceptors to check for your security needs. Also with Databases, of course you have to look into your own database performance the moment you get complex models that need to do specific performant operation, and in fact, is easy to write database your own database queries and not (always) use the Method-name generated ones. You as a developer should always gauge your database query performance, the notion that you can offload this to a framework is ridiculous. Spring's purpose is to deliver convenience and accelerate development speed in "opinioated" patterns. Its entire purpose is to auto-deliver common application components and in matter of Spring Boot (Spring Framework and Spring Boot are not the same thing), so you don't **need** to deal with it to get started, and the moment you need to deal with it because of off-normative requirements, nothing is hindering you to do it. If you are using a library/framework to integrate a web-server in you application, but you don't even know what HTTP is, or what it entails, I don't think that was ever the frameworks fault. It was the developer's fault for using something that they never bothered to even try to understand. I am fully behind your notion that developers should delve themselves deeper into how specific things work. By all means, go write your own botch version of an HTTP Server just to understand what code and concepts all go into fullfilling the specs, you will become a better developer for it. But if a customer asks for a HTTP Backend where most of the well-established patterns and protocols will suffice, I will not start by writing my own HTTP-Server Integration with my own concepts of Route definitions and RBAC. I think most of your arguments are more accurately attributed to developer laziness, and Spring definitely helps creating lazy developers make something that works, but they still do not understand at all. But a frameworks purpose is not to teach you, that is your job. Edit: Just wanted to add: There is quite a bit to dislike about Spring but I think most of the points you mentioned are not a fault of Spring or apply to any Library you will ever use for every language (depending on the given language's quirks and established standards)
Controversial? not at all. Spring is perfect for mid sized org - when it comes to enterprise... Some parts of architecture slowly become "module as service" states, which requires the service to be smaller and faster - like golang. In this state, opinionated framework becomes the burden. Architecture does not have "correct answer" but it shares one goal, less pain.
I don't agree. Before reading bullet points, I felt that you are upset that Spring Boot is doing stuff for you. If you want to have max control over HTTP and DB, write your own libraries/framework or go raw. If you do not like frames that framework gives then do not use it... I tried to answer everything you mentioned in the video. 1. Doing DI right (by using proper architecture in your app), solves the problem of uncontrolled injection. 2. Any Dependency you add is for you to help you solve problem with less code - most of crucial things are still configurable - if you need to change default configurations. 3. You sounded like you despise Annotations popularity in Spring boot. Because they do the work for you. Instead of you, writing your own Entity managers, handling transactions, using JDBC libraries you can have it from a one that handles it with usage of annotations. Do not get me wrong, Hibernate (Framework for working with Databases, that is most common used in Spring) has its own limitations. Also, it falsy to say, that it does take from you all power of writing SQL queries - you can do that with JPQL queries or simple SQL native queries(not recommended - you might loose DBMS portability) 4. "The Developers takes the path of the least resistance" - If somebody would like to use Kafka/HTTP Client/Db reposiroty in controller this would automatically mean of not approved PR and simply talks with such Dev about how to structure code correctly, so APP architecture is correct. 5. Again, Java is verbose (it is a OOP language) - annotations came to help you. You do not have to use them (some of) but it takes the boilerplate from you, which is awesome. 6. You said that functions that are (endpoints) in Controller are not used. Would you rather have it added like in NodeJs app.post('/...'). This is a controller, which should have HTTP Annotated endpoints, which makes it easily possible to just share given resource to outside world - it is that simple. I am not sure if you understand how Network part is working in Spring, I mean the use of Servlets Container like Tomcat or Netty. 7. Authentication - you should first implement basic authentication with Spring Security (important library) if you want to secure your app properly. And when you understood how it works implement JWT authorization - in the meantime you will come across Filters concept and you will know most things about how Spring Networking works. (Request comes from client and lands in your controller code to do some next things) Everybody has its own preferences, but to me Spring boot is a great option for medium - large applications. Small too, if you do not pay for RAM usage ;) Video liked
I've been working as a developer for at least 15 years, in multiple languages, PHP, Java, C# ... etc, don't know your experience, but I don't think I have an instance where there was just a DB swap without code changes or a full rewrite. "... you can do that with JPQL queries or simple SQL native queries(not recommended - you might loose DBMS portability)" -> This never made any sense to me and I hate that due to this "just in case" thing Hibernate comes with some, IMHO, shitty limitations instead of being the other way around. Do you also code "just in case" when there is no business need for that logic?
@@bacon-SG Hi, I didn't experience DB swap in an ongoing project in my career yet (and hopefully will not). I had clearly less chances than you because I've been working as a Backend/Fullstack dev for 3.5 year (Spring boot + React/Angular/Thymeleaf). I never write SQL native queries (maybe only in Integration tests as a before test setup/post test cleanup) I usually write using ready interfaces provided in JPA or write custom queries with JPQL - So this is an answer to your statement 'if I write just in case...' (leveraging Hibernate/Java DB portability functionalities) Also I can tell situation where using JPQL/JPA might be a time saver: 1) As you probably know, different DBMS have different SQL dialects. Dialects differ. So when in my company we usually use MS SQL and at some point somebody says that we go full Openshift and use self hosted Postgres instances or Devops guys say that now we buy Oracle/IBM license for Oracle/DB2 DBMS then you need to rewrite your APP's native queries, because some of them might be already broken (different dialects). When using JPA/JPQL there is no such problem, because we have abstraction layer which we do not see and which do conversion for us. 2) When doing integration tests, you might need to do some queries on DB. It might happen that locally with in memory H2 database tests will go fine, but on TEST/PROD environmnets application will not work correctly - because again your native queries will be broken on different DBMS system I think these are main advantages of using JPA interaces/JPQL instead of writing native SQL queries. I hope that explains something
@@bedlik8 I fully get why JPQL/JPA is used, yet most of the time is just extra code and extra memory for 'just in case' which as you also confirmed does not happen(at least for both of us). One thing I hate about JPQL/JPA is that there is no way to specify offset/limit without going native or going into the EntityManager which I don't fully understand but I assume the offset/limit is not native and it filters in memory which I think it's awful. It's one of the most basic operation available in most SQL dbs, like postgres, mysql, sqlite, mssql ... etc because "well it might not be available on some implementations or it is different from dialect to dialect" so we remove it so you can't do efficient queries. And again, for what? for the possibility that in the future you can change database? IMHO I rather prefer implementing the most efficient queries for the database I'm working with sacrificing the flexibility to change database (which I don't think is a great deal TBH). Your first point just does not happen or at least is very uncommon, and rewriting some queries is not the end of the world if the application is more efficient that way. On the second point, well, I agree that it simplifies your work, but testing database connections it's also kinda unusual, usually I see domain mocking, but maybe that's just my experience. Maybe I ranted a bit too much, but the main conclusion, at least for me, is that I prefer coupling the code to the database (not against database specific ORMs) in order to get the most from that database and sacrifice the speed of database provider change in the future, if there will be any. To me is like "what if the API receives a XML instead of a json, should we implement a XML parser just in case?", no we implement it when the need arises.
@@bacon-SG I get it. That is true that LIMIT/TOP is not possible with JPQL. With JPA you can have findFirst...(), but get first 100 or 500 is impossible by normal means. However, I think you could look into Paging/Pageable/PageRequest for limiting your queries result and debug how does the executed SQL query looks like. (show-sql prop with in app props). And then decide on if this query looks ok to you.
@@bacon-SG I thought I wrote comment, but it must have been deleted. Nevertheless, I understand - look into Pagination/Pageable/Pageable Request it should provide you TOP/LIMIT functionality which is not present in JPA/JPQL. You can then debug in console how does SQL look like(show-sql prop), so it meets your expectations
Fantastically worded video, encapsulating a bunch of issues affecting every part of the development world in a very elegant manner. You're absolutely right. We are engineers, not frameworkers, we should take pride in our work of solving problems explicitly and elegantly, not by muddying up the problem to the point where it's hard to tell what we're solving in the first place. This video felt genuinely passionate, not as if you were talking down to your peers; and that's something rare with so many large youtube developers nowadays (looking at you, web developer framework fanatics). It's refreshing to hear someone acknowledge that the reason most of us got into development was problem solving, not to argue over which framework with an overly modernized website claiming to be the "next best thing" is better than all the others (again, looking at you, web developer framework fanatics). It's genuinely a breath of fresh air to hear genuine down to earth concerns with the way we collectively approach our work, and I think that I speak for the majority of developers when I say thank you. Definitely earned a thumbs up and a subscription. Keep up the fantastic work.
@Query if you want to not use JPA For authentication you can alter and customize all the security filter chain Spring is focused on business logic not reinventing the wheel by parsing http calls manually which is more error prone than having something solid and well tested that already work. In spring you can test everything. You can test the controller in unit test, the repository with an actual database if you use test containers, you can test the services, the spring functions and annotation if you want. This was you can have a test suit that will always verify if something can or will go wrong at every build
I like Spring Boot due to the following reasons. It gives you awesome defaults. You select some dependencies and tools in Spring Initializer and boom you have an up-and-running application. Furthermore, it allows you to customize as much as you like. You can still learn how HTTP works, how databases work. You can actually use "lesser" abstractions when you want to. You can write your own SQL queries if you like. I think the reason why everybody "hates" on it is it is now sort of a trend to do so. I expected you told about better alternatives.
The need to simplify the setup is a very Java Problem. Moving to lesser Abstraction makes Spring kinda pointless. Nobody should ever write a SQL string or a specific dialect of it into a annotation because the abstraction is just miserable.
While I agree with some of the points you make, I still enjoy working with Spring Boot myself. Do you have any plans on making a video on java specific alternatives to spring?
I'm looking now at Javalin, and KTor. Both is based on an the idea of: There are no conventions. You, the developer explicitly decides what you want o "inject" (aka call a constructor). No magic. Also have a look at Http4K. Dropwizard is also a nice option.
Agree 100% Loving Ktor, it took the learnings of the mistakes of Spring and the success of Express.js and refined it even more and using the language features of Kotlin, which has been a joy to work with SO FAR.
The advantages of using Kotlin is that you can DSL anything, to HTML to CSS this allows you to create a unified fullstack app much like Golang with Templ. Drop-in some HTMX and you are set!
I have years of experience with Spring. It was always in some huge codebase where everything was already there and I just had to add my little thing. Then one day, I tried creating a small green field project, significantly more complex than the usual todo app, and god I hated using Spring. To understand Spring Security, the only option is to go through its code. Good f*ck*ng luck getting Spring JPA caching correct. Sometimes, I know exactly what SQL query I want, but Spring JPA hides SQL behind 5 layers of abstractions and I have no idea what Spring JPA annotation I need to use. I made the same app with Django and Go, and it just makes more sense with both of them.
you know that you can use sql queries in JpaRepository setting the flag native to true in the query annotation for using SQL the way you want, no? also you can use spring jdbc api instead of spring data jpa
@@tarmagoyf95 yeah, i have no idea why he don't use spring jdbc if he want more control over the query. so many alternative under spring umbrealla, use the one that fit your project. JPA caching problem? it's common problem encountered when one have no good grasp on persistence context, managed entity, detached entity concept.
Thats literally ORM's. Spring JPA is just another one. Typescript has 100 so it makes it a bad language? Stop saying bs everyone knows how much ORM's suck as soon as you try to build advanced queries , and there's a reason why not a whole lot of production applications use them. Besides JPA is bad, JOOQ is better , but they all suck, the same way all the typescript orms suck, the same way go orms suck. So it makes them bad languages?
The level of abstraction seems horrible lmao, never used it extensively but this definitely doesn't feel like fun as the underlying stuff is just hidden in a bunch of classes
I'm a Java developer for a decade now. And yes, all you said is completely true. I found that Quarkus is a way to cope with bad Spring antics but in the end of the day almost all the Java ecosystem runs around these concepts you listed and this is enforced by the platform itself a.k.a Jakarta EE Specifications. You don't have skill issues at all, Java developers who are talking shit in the comments either are newbies, fanatics or outright dumb. But there is hope. Ktor and Vert.x are both great projects nowadays to build Java/Kotlin web applications the right way. But well, I defend a point that if you are going to use Vert.x or Ktor, just switch to either Golang or Rust altogether.
The entire video is "I want to do abcxyz! Spring doesn't allow this! Spring is the worst framework ever created!". Yeah, a very subjective point of view. Your title should be "I'm not suitable for Spring.", not "Spring is the worst framework ever created". You like to initialize every variable and pass it in yourself, but that alone is even more difficult to maintain as a larger scale. You want to understand more about HTTP/HTTPS protocol. Yeah sure! But then what? The whole point of any web framework is to abstract away the boilerplate that you have to write to handle a single request. Developers should always know better way to deliver their code faster in production while having good background on low-level when they have time and not the way around.
Lol. He does not say, that Spring is worst. He says - any magical framework is bad. Objective. No one is suitable for Spring. Spring hides variables behind reflection, nothing could be worse that that. There are way to abstract without losing compiler protections. Only your last statement is correct, man.
Looks like the fact that spring is stable enough for years is the sign that can be used pretty well. Imperfect, absolutely. But until this moment in time, I don't really find a great stable modern fullstack framework (for enterprises) that will replace the big dog. "Java Spring, C# Asp"
@@havinhphu9331 turtle is faster than snail. The context fits perfectly with gradle and maven. compared to golang, rust, cmake, gradle is way out of league when it comes to speed and stability. especially, stability.
Just stop using any framework superficially. If you're still a rookie such that it's hard for you to take a deep dive into the implementation of an abstraction, then true, learn the basics first. Only because Spring would enable you to create a controller with simple annotations, it doesn't mean you don't have to know what's going on under the hood or simply add all the annotations without knowing what you're doing!
Yeah, also some technologies like ORM and DI aren't even specific to Spring. They're everywhere, even in Android as separate libraries and they solve a niche task perfectly.
@@FilipCodes "hate" it's a subjective experience. When this happens, it's likely the person's brain is stuck. So, it's a skill issue or a bad technology issue? Who knows? ORMs are widely used because they solve a niche task, period. If I experience an unpleasant sensation when working with ORMs, then for me it's a sign to transition from ORM to just rawdog sql queries, but at the beginning it will always be a skill issue because nobody's born knowing everything. It's an axiom.
I can't count the number of times I've said something like, "I could write that easily in SQL, but I've no idea how to do it in this ORM query builder thing" or "If I could see the HTTP headers I'd know what's wrong, but they're all obscured." This is a frustrating trend in so many frameworks that try to "simplify" and just make life more complicated. But my biggest specific beef with Spring is with debugging. Whenever you just dependency injection, it also injects so many layers of "AbstractMethodInvoker" stuff that you can't just step into and or out of methods. What are they even doing? Why does Spring have to make debugging harder? I know writing your own framework is a fool's errand, and I wouldn't inflict that maintenance headache on my colleagues. But on my own non-work projects I'll so often cut out the frustrating middle man.
Presentation - Just enough app server by Antonio Goncalves - mandatory watch if you think Spring is bad, you never knew what was before Spring, like J2EE 1.3 and J2EE 1.4 with Java 1.4 and Java 1.5 Build sample application with J2EE 1.4 and then you will realized what problem Spring solves However, J2EE evolved into Jakarta EE 10 and is very easy to use and Spring evolved into abstraction on top of abstraction to look easy (exibit A - Spring Data interfaces ) and you can learn using a debugger and ask questions like - can I see JPA query generated ?
7:16 good question *proceeds to argue that we shouldnt use a framework that has already solve a lot of the problems commonly found on software development* 🤷♂️
I agree. I can see why Spring is good at what it is doing, but the way it abstracts away so much can make implementing just little changes very challenging. I like "radical simplicity", and Spring seems like the opposite.
I am using Spring Boot at work and all I can say it is a well thought out powerful framework for serious software application development. It does require an understanding of Software Design patterns. But my goodness its quite good. I think this video was made from someone who's tied to a way of doing things thats different.
I can't relate. Spring Boot has been a breeze to use short-term and long-term. It just werks and the wide-spread conventions make it easy to jump into a project and quickly understand what is happening.
First and only time I tried Spring filled me with dread. I barely wrote any code and it simply did too many things under the hood for my comfort. First experience with trying to implement something that did not fit the standard use cases made me run away and never look back :D
This is so true. Spring is very very bad framework. And its popularity is the reason why modern Java backend is slow, bulky and insanely complex. It could be simple and faster if programmers write it in Java not in Spring
I see now! Spring and ORMs more generally are like the Tailwind and Bootstrap of the Backend world! Bootstrap and Tailwind claim to make styling easier and you "don't have to learn CSS" but you have to learn their complicated system and do inline styles or mess up your style sheet with bootstrap's cancer. Likewise, ORMs claim to make making queries easier but it makes it harder in the same way and you have to learn their weird system to do anything on top of SQL itself. So all of these are just bad abstractions. We should just use raw SQL but with a light abstraction layer that helps us create safe SQL and debug it, similar to how Styled Components helps us make CSS but with better syntax and scoping.
I agree with a lot of the things said here , but I think you are lacking nuance. Frameworks also bring some benefits to software development, like security and standardization. Yes you could build your own framework from scratch but you will probably make a lot of mistakes and make you vulnerable to potential threats you were unaware of. And that might cost your company a lot of money and reputation damage. Also from a business perspective companies want to plan for employee churn, if you are using a well known framework then it's easier to onboard new hires. Like everything in life, things a more complicated than what they appear at first. I know its cool to have a hot take opinion on things but we should always counterbalance it.
And yet, neither security not standardization require any magic at all. Use framework, use libraries, but be conscious of dependencies and indirections.
To recap: "spring is only good as long as you do pretty common stuff with it" Yes, this is why frameworks exist And let me tell you, imho when you work on large and complex codebases with hundreds of engineers, having something that enforces best practices may be a bless, because of all "customizations", maybe 30% of the are necessary while the rest could be workaround to fix past design choices that didn't age as expected
I feel like you're talking about Spring Boot, not Spring Framework. Spring Boot is exactly for that rapid development with abstractions when you create for the 50th time the same logic in app and you couldn't care less for performance. Spring Framework on the other hand just gives you structure for an enterprise app with little to no dependencies necessary, where your only concern is bean lifecycle.
Half of these points can easily be translated to any enterprise oriented framework, and the issue is most often not in the framework itself but in the architecture patterns people build around them, often half understanding why those are even used and just following tutorials. That being said there are good reasons for may of those to exist, it just sucks when you get handed some legacy project and need to unwrap what's happening there. A framework is a tool, it needs to fit to solve your problems. And just like elsewhere in programming, problems and decisions need to be documented and maintained.
I have mixed feelings about the arguments on the video. I’ve been working with NestJS and I really enjoy it. Sure, sometimes I have to do some workarounds to achieve something, but most of the time works great. At the same time I’ve been studying Go lately and really like the minimalist way of doing things, mostly relying on standard libraries. When comparing both approaches, what I really likes from frameworks is the fact that enforces you to follow patterns to design your application. When you have more on the team and company is young, things can get pretty messy.
"Annotated funcntions are just weird and wrong". Tell me you're a junior without telling me you're a junior. Spring is great, it gets the job done. Granted, there is a lot of "magic" but it's extremely systematic. If you go against the framework in your applciation, you will have a hard time. But if you're sticking to the methodology, it's a godsend. All other frameworks pale in comparison to Spring, which is why it's as popular as is is. It can seem daunting in the beginning, but I've learned to love it and I work with it every day. Also, Spring never generates source code, at no point in time. It works based on the extensive use of reflection and dynamic proxies. Spring Data generates some bytecode at runtime, but you'll never see it. And no matter what you do in Spring, there's always some sort of escape hatch which you can use to do things "your way" if needed. You know what's "weird and wrong"? Async.
I can understand where you're coming from, but I'd argue that the domain layer is far more important than the data access layer in most cases. You can fiddle around with query optimizations all you want, but unless you have a product that is actually available and in demand, you won't be making any money. Also, if you have a query that is taking 30 seconds to return, then you've done something horribly wrong farther up the call chain. At that point, it's not Spring's fault. In my experience, I've never had a Spring query take anywhere close to 30 seconds. In this day and age, there are enough concurrency solutions available in the JVM and Spring if blocking calls are really a concern. I'm of the opinion that most of your time should be spent on the domain, and the infrastructure around it should be good enough that end users won't complain, and obvious costs aren't being accrued, but hyper optimizing your infrastructure so that not a single millisecond is wasted has seriously diminishing returns.
I think you should listen less to tech youtubers and catchphrases like "magic is bad", "abstraction is bad" or "simplicity is better than complexity" and try to understand why people are actually using what they are using, why they invented these things and just that, criticize these things while providing alternative and good solutions to the problems these things were created to solve. This is what will make you a good engineer, and not "learning HTPP and SQL".
how does learning Spring's abstraction make me a better engineer than learning HTTP or SQL. My time learning how Spring works will be mostly rendered useless if I have to use new framework or something else.
@@yellomango_6440that's part of being an engineer my friend. You need to know both, the basics to know what the abstractions are doing, and the framework to build fast so the business is profitable and you can keep your job ;) why do you think most startups are using the JavaScript (craziness) full stack?
@@yellomango_6440 Because ex nihilo nihil fit, if something exists there is a parallel between this given thing and the others that already exist. If you learn Spring you will absolutely transfer this knowledge to the next framework you use (and even when learning HTTP and SQL you will understand why they made some design choices if you mastered them). It is the same principle as learning a language or a library, knowledge is generally transfeerable. And you can absolutely learn both (Spring and the principles).
@@yellomango_6440 No, in the same way that learning C or Java is not useless when you later learn Rust or Go. The experience with other languages and frameworks helps you learn new ones faster as you are already familiar with the concepts involved and just need to learn the differences rather than everything from scratch. In most jobs you'll have, knowing the frameworks well is more useful than the nitty-gritty details of HTTP or SQL. You'll need to know the basics, but you don't need to be able to write a SQL parser or implement your own HTTP server. Those exist already and you're far better off using one that someone else wrote that thousands or millions of other developers use and have tested to make sure it works. Focus on the business logic and the tools you need for that.
People in the comments don't seem to understand that learning spring/hibernate/any annotation driven framework is an experience that requires you to strictly read documentation(official or not) for EVERYTHING you need to implement/change(and if you can't find in the docs an answer for a problem you have then good f-ng luck), as reading the source code and command clicking/debugging to figure out what's going on is pretty much impossible. A side effect of this annotation driven experience is that it's thrown into the garbage bin once you move to different tech stack (go, kotlin with ktor, rust, idk what else). That shouldn't be the case. It's not normal. You shouldn't have to learn a framework with its own rules which you can't figure out by yourself, isn't intuitive and the experience helps you very little once you move. Worked with spring once, hard pass since then. Agreed with many people that say hibernate is even worse.
spring is a framework that in a long run, will force you to read what code a spring developer has written. For learning, its a boon but when stuck on an actual prod issue and you need a quicksolve, it will definetely give you headaches. Still remember an issue where our client gave us an api which had request body in GET request method. Python can easily invoke such apis but to no surprise, Java can't. Reaching to this conclusion took hrs of debugging😅. When your application doesnt start simply because you missed an annotation, where no error message ka point out towards which annotation is missing is a different level of nightmare. Also things start to get quite interesting when you learn how the injections are actually powered😂hint: reflections😉
I've been working with java and spring since 2014 and got certified, I think spring will still be there. But, in my new project I replace spring security with keycloak, spring cloud with linkerd/istio, then I need my application more lightweight and i see kotlin and ktor working good together, I try it and I enjoy it.
I tried Java and Spring being too magic put me off. (I know that is apples to pears, but the reason I wanted to learn Java was because of all the jobs wanting Spring)
You can also use Spring without annotations, but that’s definitely not the common usage of the framework you’ll see in the real world. Reducing the magic in Spring helps, but it takes effort.
Spring offers you the flexibility to not worry about the http or you directly deal the http request and response Just read about spring boot little more before the video
I think what make Spring hard to use, is it approach to use classpath scanning to bind the code, instead of using pure Java. It make Spring application lose its strength in static type, and turn into a hard to read mess. It make Spring no longer Java.
It seems like bloat and indirection begets bloat and indirection. Spring is all about insulating you from all the underlying technology, but every commercial Spring project I've worked has had tons of custom abstractions for insulating you from Spring itself. So you are not only actively discouraged from learning and leveraging HTTP and SQL, you're even discouraged from learning and leveraging Spring itself.
I didn't know about Spring in particular but I definitely agree that putting a lot of abstractions around rather simple concepts makes no sense. It might be easier to write code without understanding what's beneath but debugging all of that can be almost impossible in some cases.
I know I shouldn't, but I have to comment.... I actually use spring in production and I do have a good understanding of all the concepts. I my observation hibernate does a pretty good job of writing performant queries and sometimes it is way better than I am. I could deal with everything if I wanted. But I have to say, that spring is a solid and fast tool that gets me readable code that everyone in my team can understand and reason about. I would be using dependency injection anyways, so it is nice to have it inside my framework. My focus is make it work fast and don't spend time on solving problems that someone else already solved. If I wanted to do everything myself I would use rust or C and not Java. Just think about all the waste that is in the Java standard library that you won't be using 99.9% of the time. Java itself is inherently full of magic and shit I have no control over like class loading, garbage collection, preferences, introspection. By this logic you should avoid using Java and kotlin altogether and ant try macro assembly or maybe the language without a standard library (rust)... Even if my comment is meant to be provocative I don't mean I'll to anyone. If it was that bad nobody would be using it. In my practical experience most problems I find with spring is me not reading the manual and just winging shit I should have researched beforehand.
Complex enterprise applications need complex frameworks which you usually don't fully understand in 6 months. All your points are valid from junior point of view, but when you are working on enterprise level, you well how spring get it right. Nice you don't need to use someone else code, you're welcome to implement your http client in Assembly, by the way, you don't use Autowired, read the docs!!
Spring doesn't really do that much for complex enterprise applications either. Nothing is worse than being a junior developer and trying to run your application and getting a huge, opaque error from some abstract factory, googling it, and getting no responses. With the other libraries and frameworks I've used, I can press CTRL-B to instantly see the implementation and look at what might be going wrong, I can attach a debugger and know where to put breakpoints. With Spring, you have some 30+ frames of reflective access that's basically impossible to navigate.
Just pinning a comment to address common feedback:
1. Skill Issue
- Yeah, I actually agree. If I was perfect and never made mistakes I don't think things like magic would be a problem. But I do make mistakes, and I do have skill issues. This is actually why I favour simple technologies. I don't want to blow my leg off when I inevitably shoot myself in the foot.
2. Alternatives?
- Ktor for Kotlin, Javalin for Java, pretty much any the Go web frameworks are good. The most popular web framework is usually a good option for most other languages
not trusting big framework is pretty good.
but we gotta understand why python got so big in the market despite of its awful processing efficiency.
but, spring security can kiss my ass.
Vert.x for Java is also good.
@@tom-delalande thanks for the alternatives. I will definitely check them out
Skill issue is when you can't do something without a framework or a scripting language.
Try to do the same functionality in C. I can, cause i know the inner working of the computer and have principles in networking, as well as protocols adopted.
High level scriptinmg and frameworks will help you go fast but you'll learn nothing.
I'll stick to programming, much more a manly thing to do.
@@rebel1324yeah, flask and django are easy to understand, very customizable and imho a lot easier to develop on than Spring.
we need Prime to react to this ASAP
It'll be an hour and a half video...
Prime couldn't care less about Java environment
Yes!
@@12crenshaw he should have some experience interacting with Spring since Netflix is using it
If this is about Rust he will definitely going to react immediately.
Hello, minor Spring Contributor and Java Developer here o/
I'll cover a general misconception, and then dig into some incorrect points here. You're perfectly fine to bring up these points, and it doesn't mean your grievances aren't valid per-say. Simply want to provide some better understanding of the situation. Note that I'll use Java EE/Java for what is now Jakarta EE/Jakarta, as Oracle gave the rights to the Open Source side of Java.
Spring is best viewed as an adapter layer to other standards or libraries. Many of the issues brought up are either due to underlying standards (JPA/Hibernate, Java Servlets, etc), or a misunderstanding of the history of Java, specifically Java EE. Yes Spring relies heavily on "annotation magic", but that's because it's trying to expose a single entry point to many standards. For example the "@Transactional" can hook into many Transactional managers, meaning regardless of the underlying DB, you don't need to write custom code for a simple transaction. This means you get the same problem you get in any type of adapter approach, being that once behavior has to be customized, you either need the adapter to change (Spring does a good job of this), or bypassed (Far more common of developers to do this). Many issues I've seen with Spring code are Developers not knowing, and by extension misusing, the framework.
I believe my explanation of an adapter covers 1:23, however I'll also plug in that Spring didn't invent annotations. This approach has been part of the official Java "standard" since as far back as 2005 (See JSR-181), and Spring even provides a more Functional Approach, docs.spring.io/spring-framework/reference/web/webmvc-functional.html
1:46, this is more a result of Java Servlet Filters, the flow of an HTTP Request/Response is well defined in the spec, jakarta.ee/specifications/servlet/6.1/jakarta-servlet-spec-6.1.pdf
2:24 mentioned with JSR-181, this is actually incredibly normal in the world of Java, and has exists for decades.
2:38 Developers don't have a strong understanding of HTTP. They have a strong understanding of the structure of the request/response. The moment you start asking questions like the usage of the X prefix, the reason to upgrade from HTTP 1.1 -> HTTP.2, etc, most developers will fall apart. This is totally normal and fine, but it means from a framework perspective you mostly care about how to expose the structure, and Spring has pages of documentation on how it does that.
3:18 , if you want full access, just use `public ResponseEntity myFunction(RequestEntity
Really good answer.
Maybe should be pinned.
Spring is a framework built on top of Java the language and Java the tooling infrastructure. All it's weirdness is coming from that context.
That being said, it not having a defacto-standard query builder to circumvent JPA is the only thing that is really annoying me. Hibernate being default for persistence is just giving haters ammunition. Something simple for typesafe sql query building that builds on top of composition and fluid builder patterns would be awesome.
But I guess Spring thinks itself really more like an adapter, therefore no custom impls for that stuff. Sad.
Just don't use Java. Problem: solved.
You see, but all of this would require him to learn the framework, but seems like it's too much work for him, so instead he prefers to reinvent the wheel and standards, obviously because his boss doesn't pay him to do so 🤷♂️
And off course, never forget, Spring is the worst. And how does he know that? Because he doesn't want to learn it!!! 🤦♂️
is this crain?
just dont use java
Young one, you don't want to work with enterprise frameworks before Spring. Spring was a fresh start.
This is true, I completely forgot what a nightmare learning Enterprise Java was
Yeah. I don't have flashbacks about Spring. But I do have about setting up db connection in Glassfish. Brr...
They went from garbage to still not good. I'm no fan of .NET by any means but it makes more sense to compare ASP with Spring & they just got many things right. Even in the strict OOP Space there are way better solutions. TAnd I'm pretty sure ther are better things in the JVM space as well.
@@deado7282 Wonder why a framework like Play doesn't get as much traction as Spring.
My org has the core features written in pre spring era and its such a disaster that no one dares to touch it unless they are forced to.
There are so many misconceptions in this video, that it's really hard to even start with one. for example: "your domain model isn't guaranteed to be identical to your database one either (which is correct), this is a bold assumption that spring makes" - thats simply wrong. spring does not make this assumption at all, nothing is stopping you from going fully hexagonal and completely decouple your entities from your business and services models. spring does not even force you to use JPA or hibernate either. If you would want, you could write raw queries and execute them via a plain jdbc connection.
Yeah, I don't know why he was going on about SQL. Nothing is stopping you from writing raw SQL queries.
Good! I think so too.
I truly pray I will never need to maintain an app, where the previous developer created his own framework
I've had to do that. We spent the better part of 3 months rewriting it to use the company standard (Spring Boot). The guy who initially wrote it created his own system for everything and documented nothing. It was hell.
You don't need any framework to create an app, 3rd party or your own.
My biggest gripe with Spring is actually Spring Security.
When I tried to pass some user data into a model, I gouged my eyes out when trying to establish which bean is visible when and what data is inside
I used Spring Security in Grails back in the 2.x and 3.x days... It was actually kind of cool as the Spring Security Plugin handled all the nastyness for us.
would you rather:
1) spend 12 hours in a cage with 10 hungry lions and bears
2) read spring security docs
@@gangsterism 24 hours and 20 lions and we have a deal
@@gangsterismeasily the lions
I feel this way, but about Hibernate instead. Absolutely the worst abstraction layer I’ve used in my life. It was a terrible decision to ever make, from top to bottom.
thank you. the first step to quitting addiction is to acknowledge it.
you're goddamn right!
bro woke up and chose violence right from 00:01
Wow, I don't think I've ever seen a video where I disagree with so much of the content.
Magic doesn't exist. I despise all the high-level frameworks/tools that try to do everything for you, it literally *takes away* my ability to understand the program and program. I'm here because I'm looking to save time, not because I don't know how to do something. Unreal Engine, web dev frameworks and libraries, even broadcasting in numpy/PyTorch etc. . I will take extra boilerplate if it means that I know what to expect and that things are intuitive. If you're going to make abstractions, make them crisp. I'm a producer not a consumer. Thanks for coming to my TedTalk, I don't know where else to vent about it with people who may be somewhat like-minded lol
This is why I quit java development. When something went wrong it always was like 4 abstraction layers down, in a class I have never seen or interacted with, that is interacting with a bunch of other classes that I also have never seen or interacted with.
This is why I gave up coding in Java, then C++, C, Assembly and binary to code using transistors, I am jumping in now into electron spin microcode which is zero-overhead abstraction and the documentation is consistent across the known Universe.
@@BossFlight nah fam it's not an abstraction issue but an "unreliable abstraction" issue, which was much worse on java-based frameworks than C# or Go or even Python at the time. If you abstract things the framework should be solid like rock, I should not be required to go in and troubleshoot the framework of your framework or the core java classes because something broke at some level.
@@marcogenovesi8570 I have a friend who is really good at Java and also really likes it and I don't know how. I end up depth-first searching everything which can work in some limited ways but with a bloated system in a bloated language doesn't go well. I can't hold everything in my working memory and it feels like people who're good with it just pull constructs out of thin air in their mind and are somehow able to work with them. I think I have really good pattern recognition but limited working memory so for systems built on patterns (and, meaningful ones) I can work really well with them but for ones with a lot of arbitrary design decisions I just can't. I've tried really hard
@@BossFlight LOL it's true and I take the point, I guess what I meant by magic doesn't exist is that we have a limited number of patterns at our disposal before they essentially become arbitrarily mixing and matching/become obsolete and just bloat things. I do agree though and I think sometimes my bias in the other direction (i.e. toward doing everything explicitly) hinders more than it helps. Balance is hard and there's not a perfect answer to anything really
Taking this points into account you would also probably hate laravel
And Django
When Spring Boot was first being rolled out, it was being marketed as a rapid prototyping tool. In fact, the company I worked at saw it as a toy. We favored the non-boot XML-driven config BECAUSE it was way more clear what was going on. I think the issue is that the industry has moved on to using Boot as a production standard.
It sounds good for prototyping especially when you have a use case requiring multi-platform support. Although I'd probably pick up Phoenix +Elixir.
Speaking of Boot in production, the actuator is really quite useful. As far as keeping config understandable, the annotations work as well or better than XML once you get used to them. The key is to be consistent and logical. Also, tooling such as STS and IDEA can be a great help.
so your problem is that you didnt make the choice to use a low level http framework
first time using spring: "woah this is so cool I don't have to write queries anymore"
six months into spring: "why tf it's expecting a long, I defined it as byte[]/bytea"
(I still don't know why, I just know writing the query myself solved it)
this is the reason I love Go so much. I have a background with Spring and Aspnet Core. Most of the time I am stuck reading the documentation to understand how magic works just for simple modification from the happy path.
Welcome to all JS Frameworks
Java is NOT Javascript.
@@rein5174 that`s not what he said
Controversival Take:
Don't use something you don't understand.
Spring's Documentation is actually fairly easy to understand. Of course it can be big in size, but that entirely depends on the Spring modules you bundle and use within your application.
Spring Boot will autoconfigure the basic standard for you (depending on the module you might have to configure a base yourself, but again Documentation!). The moment you deviate from that standard of course you have to dig in to documentation and implement it yourself. In fact, you can reconfigure most partial components Spring uses by providing an implementation for yourself.
And also you don't have to even use every Spring module under the sun. Want to write your own Security module? Go ducking do it, you just need to integrate it with Spring Web or whatever you need. Don't want to use Spring Web, then write your own Code to instantiate a Web-Server and define routes and create interceptors to check for your security needs.
Also with Databases, of course you have to look into your own database performance the moment you get complex models that need to do specific performant operation, and in fact, is easy to write database your own database queries and not (always) use the Method-name generated ones. You as a developer should always gauge your database query performance, the notion that you can offload this to a framework is ridiculous.
Spring's purpose is to deliver convenience and accelerate development speed in "opinioated" patterns. Its entire purpose is to auto-deliver common application components and in matter of Spring Boot (Spring Framework and Spring Boot are not the same thing), so you don't **need** to deal with it to get started, and the moment you need to deal with it because of off-normative requirements, nothing is hindering you to do it.
If you are using a library/framework to integrate a web-server in you application, but you don't even know what HTTP is, or what it entails, I don't think that was ever the frameworks fault. It was the developer's fault for using something that they never bothered to even try to understand.
I am fully behind your notion that developers should delve themselves deeper into how specific things work. By all means, go write your own botch version of an HTTP Server just to understand what code and concepts all go into fullfilling the specs, you will become a better developer for it.
But if a customer asks for a HTTP Backend where most of the well-established patterns and protocols will suffice, I will not start by writing my own HTTP-Server Integration with my own concepts of Route definitions and RBAC.
I think most of your arguments are more accurately attributed to developer laziness, and Spring definitely helps creating lazy developers make something that works, but they still do not understand at all. But a frameworks purpose is not to teach you, that is your job.
Edit: Just wanted to add:
There is quite a bit to dislike about Spring but I think most of the points you mentioned are not a fault of Spring or apply to any Library you will ever use for every language (depending on the given language's quirks and established standards)
Controversial? not at all.
Spring is perfect for mid sized org - when it comes to enterprise...
Some parts of architecture slowly become "module as service" states, which requires the service to be smaller and faster - like golang.
In this state, opinionated framework becomes the burden.
Architecture does not have "correct answer" but it shares one goal, less pain.
I ain't reading all that
I don't agree. Before reading bullet points, I felt that you are upset that Spring Boot is doing stuff for you. If you want to have max control over HTTP and DB, write your own libraries/framework or go raw. If you do not like frames that framework gives then do not use it... I tried to answer everything you mentioned in the video.
1. Doing DI right (by using proper architecture in your app), solves the problem of uncontrolled injection.
2. Any Dependency you add is for you to help you solve problem with less code - most of crucial things are still configurable - if you need to change default configurations.
3. You sounded like you despise Annotations popularity in Spring boot. Because they do the work for you. Instead of you, writing your own Entity managers, handling transactions, using JDBC libraries you can have it from a one that handles it with usage of annotations. Do not get me wrong, Hibernate (Framework for working with Databases, that is most common used in Spring) has its own limitations. Also, it falsy to say, that it does take from you all power of writing SQL queries - you can do that with JPQL queries or simple SQL native queries(not recommended - you might loose DBMS portability)
4. "The Developers takes the path of the least resistance" - If somebody would like to use Kafka/HTTP Client/Db reposiroty in controller this would automatically mean of not approved PR and simply talks with such Dev about how to structure code correctly, so APP architecture is correct.
5. Again, Java is verbose (it is a OOP language) - annotations came to help you. You do not have to use them (some of) but it takes the boilerplate from you, which is awesome.
6. You said that functions that are (endpoints) in Controller are not used. Would you rather have it added like in NodeJs app.post('/...'). This is a controller, which should have HTTP Annotated endpoints, which makes it easily possible to just share given resource to outside world - it is that simple. I am not sure if you understand how Network part is working in Spring, I mean the use of Servlets Container like Tomcat or Netty.
7. Authentication - you should first implement basic authentication with Spring Security (important library) if you want to secure your app properly. And when you understood how it works implement JWT authorization - in the meantime you will come across Filters concept and you will know most things about how Spring Networking works. (Request comes from client and lands in your controller code to do some next things)
Everybody has its own preferences, but to me Spring boot is a great option for medium - large applications. Small too, if you do not pay for RAM usage ;)
Video liked
I've been working as a developer for at least 15 years, in multiple languages, PHP, Java, C# ... etc, don't know your experience, but I don't think I have an instance where there was just a DB swap without code changes or a full rewrite.
"... you can do that with JPQL queries or simple SQL native queries(not recommended - you might loose DBMS portability)" -> This never made any sense to me and I hate that due to this "just in case" thing Hibernate comes with some, IMHO, shitty limitations instead of being the other way around. Do you also code "just in case" when there is no business need for that logic?
@@bacon-SG Hi, I didn't experience DB swap in an ongoing project in my career yet (and hopefully will not). I had clearly less chances than you because I've been working as a Backend/Fullstack dev for 3.5 year (Spring boot + React/Angular/Thymeleaf).
I never write SQL native queries (maybe only in Integration tests as a before test setup/post test cleanup) I usually write using ready interfaces provided in JPA or write custom queries with JPQL - So this is an answer to your statement 'if I write just in case...' (leveraging Hibernate/Java DB portability functionalities)
Also I can tell situation where using JPQL/JPA might be a time saver:
1) As you probably know, different DBMS have different SQL dialects. Dialects differ. So when in my company we usually use MS SQL and at some point somebody says that we go full Openshift and use self hosted Postgres instances or Devops guys say that now we buy Oracle/IBM license for Oracle/DB2 DBMS then you need to rewrite your APP's native queries, because some of them might be already broken (different dialects). When using JPA/JPQL there is no such problem, because we have abstraction layer which we do not see and which do conversion for us.
2) When doing integration tests, you might need to do some queries on DB. It might happen that locally with in memory H2 database tests will go fine, but on TEST/PROD environmnets application will not work correctly - because again your native queries will be broken on different DBMS system
I think these are main advantages of using JPA interaces/JPQL instead of writing native SQL queries. I hope that explains something
@@bedlik8 I fully get why JPQL/JPA is used, yet most of the time is just extra code and extra memory for 'just in case' which as you also confirmed does not happen(at least for both of us). One thing I hate about JPQL/JPA is that there is no way to specify offset/limit without going native or going into the EntityManager which I don't fully understand but I assume the offset/limit is not native and it filters in memory which I think it's awful. It's one of the most basic operation available in most SQL dbs, like postgres, mysql, sqlite, mssql ... etc because "well it might not be available on some implementations or it is different from dialect to dialect" so we remove it so you can't do efficient queries. And again, for what? for the possibility that in the future you can change database? IMHO I rather prefer implementing the most efficient queries for the database I'm working with sacrificing the flexibility to change database (which I don't think is a great deal TBH). Your first point just does not happen or at least is very uncommon, and rewriting some queries is not the end of the world if the application is more efficient that way.
On the second point, well, I agree that it simplifies your work, but testing database connections it's also kinda unusual, usually I see domain mocking, but maybe that's just my experience.
Maybe I ranted a bit too much, but the main conclusion, at least for me, is that I prefer coupling the code to the database (not against database specific ORMs) in order to get the most from that database and sacrifice the speed of database provider change in the future, if there will be any. To me is like "what if the API receives a XML instead of a json, should we implement a XML parser just in case?", no we implement it when the need arises.
@@bacon-SG I get it. That is true that LIMIT/TOP is not possible with JPQL. With JPA you can have findFirst...(), but get first 100 or 500 is impossible by normal means. However, I think you could look into Paging/Pageable/PageRequest for limiting your queries result and debug how does the executed SQL query looks like. (show-sql prop with in app props). And then decide on if this query looks ok to you.
@@bacon-SG I thought I wrote comment, but it must have been deleted. Nevertheless, I understand - look into Pagination/Pageable/Pageable Request it should provide you TOP/LIMIT functionality which is not present in JPA/JPQL. You can then debug in console how does SQL look like(show-sql prop), so it meets your expectations
Fantastically worded video, encapsulating a bunch of issues affecting every part of the development world in a very elegant manner. You're absolutely right. We are engineers, not frameworkers, we should take pride in our work of solving problems explicitly and elegantly, not by muddying up the problem to the point where it's hard to tell what we're solving in the first place. This video felt genuinely passionate, not as if you were talking down to your peers; and that's something rare with so many large youtube developers nowadays (looking at you, web developer framework fanatics). It's refreshing to hear someone acknowledge that the reason most of us got into development was problem solving, not to argue over which framework with an overly modernized website claiming to be the "next best thing" is better than all the others (again, looking at you, web developer framework fanatics). It's genuinely a breath of fresh air to hear genuine down to earth concerns with the way we collectively approach our work, and I think that I speak for the majority of developers when I say thank you.
Definitely earned a thumbs up and a subscription. Keep up the fantastic work.
@Query if you want to not use JPA
For authentication you can alter and customize all the security filter chain
Spring is focused on business logic not reinventing the wheel by parsing http calls manually which is more error prone than having something solid and well tested that already work.
In spring you can test everything. You can test the controller in unit test, the repository with an actual database if you use test containers, you can test the services, the spring functions and annotation if you want. This was you can have a test suit that will always verify if something can or will go wrong at every build
I like Spring Boot due to the following reasons. It gives you awesome defaults. You select some dependencies and tools in Spring Initializer and boom you have an up-and-running application. Furthermore, it allows you to customize as much as you like. You can still learn how HTTP works, how databases work. You can actually use "lesser" abstractions when you want to. You can write your own SQL queries if you like. I think the reason why everybody "hates" on it is it is now sort of a trend to do so. I expected you told about better alternatives.
The need to simplify the setup is a very Java Problem.
Moving to lesser Abstraction makes Spring kinda pointless.
Nobody should ever write a SQL string or a specific dialect of it into a annotation because the abstraction is just miserable.
While I agree with some of the points you make, I still enjoy working with Spring Boot myself. Do you have any plans on making a video on java specific alternatives to spring?
I'm looking now at Javalin, and KTor. Both is based on an the idea of: There are no conventions. You, the developer explicitly decides what you want o "inject" (aka call a constructor). No magic. Also have a look at Http4K. Dropwizard is also a nice option.
I've got to chime in to say don't use Spring without Spring Boot unless you have a very, very good reason.
Thank you for saying it! but all enterprises just love this complicated mess
Agree 100%
Loving Ktor, it took the learnings of the mistakes of Spring and the success of Express.js and refined it even more and using the language features of Kotlin, which has been a joy to work with SO FAR.
The advantages of using Kotlin is that you can DSL anything, to HTML to CSS this allows you to create a unified fullstack app much like Golang with Templ. Drop-in some HTMX and you are set!
The points you made in the video applies not only to Spring but to Frameworks in general.
I have years of experience with Spring. It was always in some huge codebase where everything was already there and I just had to add my little thing. Then one day, I tried creating a small green field project, significantly more complex than the usual todo app, and god I hated using Spring. To understand Spring Security, the only option is to go through its code. Good f*ck*ng luck getting Spring JPA caching correct. Sometimes, I know exactly what SQL query I want, but Spring JPA hides SQL behind 5 layers of abstractions and I have no idea what Spring JPA annotation I need to use. I made the same app with Django and Go, and it just makes more sense with both of them.
you know that you can use sql queries in JpaRepository setting the flag native to true in the query annotation for using SQL the way you want, no? also you can use spring jdbc api instead of spring data jpa
Sounds like the type of problems when you try to solve a problem without looking into documentation
@@tarmagoyf95 yeah, i have no idea why he don't use spring jdbc if he want more control over the query. so many alternative under spring umbrealla, use the one that fit your project. JPA caching problem? it's common problem encountered when one have no good grasp on persistence context, managed entity, detached entity concept.
You can literally set property and JPA will print which queries it executed in console.
Thats literally ORM's. Spring JPA is just another one. Typescript has 100 so it makes it a bad language? Stop saying bs everyone knows how much ORM's suck as soon as you try to build advanced queries , and there's a reason why not a whole lot of production applications use them. Besides JPA is bad, JOOQ is better , but they all suck, the same way all the typescript orms suck, the same way go orms suck. So it makes them bad languages?
The level of abstraction seems horrible lmao, never used it extensively but this definitely doesn't feel like fun as the underlying stuff is just hidden in a bunch of classes
I'm a Java developer for a decade now. And yes, all you said is completely true. I found that Quarkus is a way to cope with bad Spring antics but in the end of the day almost all the Java ecosystem runs around these concepts you listed and this is enforced by the platform itself a.k.a Jakarta EE Specifications.
You don't have skill issues at all, Java developers who are talking shit in the comments either are newbies, fanatics or outright dumb.
But there is hope. Ktor and Vert.x are both great projects nowadays to build Java/Kotlin web applications the right way. But well, I defend a point that if you are going to use Vert.x or Ktor, just switch to either Golang or Rust altogether.
Or use Java. I, be used Quarkus once, it has same problems.
The entire video is "I want to do abcxyz! Spring doesn't allow this! Spring is the worst framework ever created!". Yeah, a very subjective point of view. Your title should be "I'm not suitable for Spring.", not "Spring is the worst framework ever created". You like to initialize every variable and pass it in yourself, but that alone is even more difficult to maintain as a larger scale. You want to understand more about HTTP/HTTPS protocol. Yeah sure! But then what? The whole point of any web framework is to abstract away the boilerplate that you have to write to handle a single request. Developers should always know better way to deliver their code faster in production while having good background on low-level when they have time and not the way around.
Lol. He does not say, that Spring is worst. He says - any magical framework is bad. Objective. No one is suitable for Spring. Spring hides variables behind reflection, nothing could be worse that that. There are way to abstract without losing compiler protections. Only your last statement is correct, man.
Prime gonna be knocking on your doors by midnight
Looks like the fact that spring is stable enough for years is the sign that can be used pretty well.
Imperfect, absolutely.
But until this moment in time, I don't really find a great stable modern fullstack framework (for enterprises) that will replace the big dog. "Java Spring, C# Asp"
my biggest hate is on auto configuration.
AutoConfiguration feels like opt-out features of sketchy services.
dont get me started with gradle
what about gradle? It is advertised as faster than maven.
@@havinhphu9331 turtle is faster than snail. The context fits perfectly with gradle and maven.
compared to golang, rust, cmake, gradle is way out of league when it comes to speed and stability.
especially, stability.
I've luckily never used Spring, but this is based.
Just stop using any framework superficially. If you're still a rookie such that it's hard for you to take a deep dive into the implementation of an abstraction, then true, learn the basics first. Only because Spring would enable you to create a controller with simple annotations, it doesn't mean you don't have to know what's going on under the hood or simply add all the annotations without knowing what you're doing!
If "skill issue" was a video...
Nah Spring is just terrible
the point of frameworks and libraries should be to make things easier, not harder
Yeah, also some technologies like ORM and DI aren't even specific to Spring. They're everywhere, even in Android as separate libraries and they solve a niche task perfectly.
@@ThisDaveAndThatJohn ppl seem to hate ORMs but somehow most of them are using it so what gives?
@@FilipCodes "hate" it's a subjective experience. When this happens, it's likely the person's brain is stuck. So, it's a skill issue or a bad technology issue? Who knows? ORMs are widely used because they solve a niche task, period. If I experience an unpleasant sensation when working with ORMs, then for me it's a sign to transition from ORM to just rawdog sql queries, but at the beginning it will always be a skill issue because nobody's born knowing everything. It's an axiom.
I can't count the number of times I've said something like, "I could write that easily in SQL, but I've no idea how to do it in this ORM query builder thing" or "If I could see the HTTP headers I'd know what's wrong, but they're all obscured." This is a frustrating trend in so many frameworks that try to "simplify" and just make life more complicated.
But my biggest specific beef with Spring is with debugging. Whenever you just dependency injection, it also injects so many layers of "AbstractMethodInvoker" stuff that you can't just step into and or out of methods. What are they even doing? Why does Spring have to make debugging harder?
I know writing your own framework is a fool's errand, and I wouldn't inflict that maintenance headache on my colleagues. But on my own non-work projects I'll so often cut out the frustrating middle man.
I use whatever my client tells me. I don’t concern myself with whether it’s the best or the worst-just make sure the check clears.
Uhm, its a framework, its supposed to do all these things you dont like.
I'll stop using Spring when it stops paying my bills.
But seriously tho, it can be very confusing at times
OOP people are addicts... their substance of choice is overuse of abstractions.
Presentation - Just enough app server by Antonio Goncalves - mandatory watch
if you think Spring is bad, you never knew what was before Spring, like J2EE 1.3 and J2EE 1.4 with Java 1.4 and Java 1.5
Build sample application with J2EE 1.4 and then you will realized what problem Spring solves
However, J2EE evolved into Jakarta EE 10 and is very easy to use and Spring evolved into abstraction on top of abstraction to look easy (exibit A - Spring Data interfaces )
and you can learn using a debugger and ask questions like - can I see JPA query generated ?
7:16 good question
*proceeds to argue that we shouldnt use a framework that has already solve a lot of the problems commonly found on software development*
🤷♂️
This is so true. I hate spring. Debugging is such a nightmare
I agree. I can see why Spring is good at what it is doing, but the way it abstracts away so much can make implementing just little changes very challenging. I like "radical simplicity", and Spring seems like the opposite.
I am using Spring Boot at work and all I can say it is a well thought out powerful framework for serious software application development. It does require an understanding of Software Design patterns. But my goodness its quite good. I think this video was made from someone who's tied to a way of doing things thats different.
This but for react
I can't relate. Spring Boot has been a breeze to use short-term and long-term.
It just werks and the wide-spread conventions make it easy to jump into a project and quickly understand what is happening.
*slowly moves mouse over spring application close button*
Spring DI is the dumbest design imaginable. At the end of the day you add a minute of startup time to have some glorified Global Variables.
First and only time I tried Spring filled me with dread. I barely wrote any code and it simply did too many things under the hood for my comfort. First experience with trying to implement something that did not fit the standard use cases made me run away and never look back :D
This is so true. Spring is very very bad framework. And its popularity is the reason why modern Java backend is slow, bulky and insanely complex. It could be simple and faster if programmers write it in Java not in Spring
I see now! Spring and ORMs more generally are like the Tailwind and Bootstrap of the Backend world!
Bootstrap and Tailwind claim to make styling easier and you "don't have to learn CSS" but you have to learn their complicated system and do inline styles or mess up your style sheet with bootstrap's cancer. Likewise, ORMs claim to make making queries easier but it makes it harder in the same way and you have to learn their weird system to do anything on top of SQL itself.
So all of these are just bad abstractions.
We should just use raw SQL but with a light abstraction layer that helps us create safe SQL and debug it, similar to how Styled Components helps us make CSS but with better syntax and scoping.
True. A lot of this applies to Angular as well.
Yes
This video is the sounds of my heart. ❤
I agree with a lot of the things said here , but I think you are lacking nuance. Frameworks also bring some benefits to software development, like security and standardization. Yes you could build your own framework from scratch but you will probably make a lot of mistakes and make you vulnerable to potential threats you were unaware of. And that might cost your company a lot of money and reputation damage. Also from a business perspective companies want to plan for employee churn, if you are using a well known framework then it's easier to onboard new hires. Like everything in life, things a more complicated than what they appear at first. I know its cool to have a hot take opinion on things but we should always counterbalance it.
And yet, neither security not standardization require any magic at all. Use framework, use libraries, but be conscious of dependencies and indirections.
To recap: "spring is only good as long as you do pretty common stuff with it"
Yes, this is why frameworks exist
And let me tell you, imho when you work on large and complex codebases with hundreds of engineers, having something that enforces best practices may be a bless, because of all "customizations", maybe 30% of the are necessary while the rest could be workaround to fix past design choices that didn't age as expected
Great video, same applies to most full stack frameworks in most languages. All focused on short term goals.
I feel like you're talking about Spring Boot, not Spring Framework. Spring Boot is exactly for that rapid development with abstractions when you create for the 50th time the same logic in app and you couldn't care less for performance. Spring Framework on the other hand just gives you structure for an enterprise app with little to no dependencies necessary, where your only concern is bean lifecycle.
Half of these points can easily be translated to any enterprise oriented framework, and the issue is most often not in the framework itself but in the architecture patterns people build around them, often half understanding why those are even used and just following tutorials. That being said there are good reasons for may of those to exist, it just sucks when you get handed some legacy project and need to unwrap what's happening there.
A framework is a tool, it needs to fit to solve your problems. And just like elsewhere in programming, problems and decisions need to be documented and maintained.
I totally agree with you. But Spring make us find job more easier. Almost all Java job need to use Spring.
Beautifully said. Getting spring PTSD flashbacks.
I have mixed feelings about the arguments on the video. I’ve been working with NestJS and I really enjoy it. Sure, sometimes I have to do some workarounds to achieve something, but most of the time works great. At the same time I’ve been studying Go lately and really like the minimalist way of doing things, mostly relying on standard libraries. When comparing both approaches, what I really likes from frameworks is the fact that enforces you to follow patterns to design your application. When you have more on the team and company is young, things can get pretty messy.
"Annotated funcntions are just weird and wrong". Tell me you're a junior without telling me you're a junior. Spring is great, it gets the job done. Granted, there is a lot of "magic" but it's extremely systematic. If you go against the framework in your applciation, you will have a hard time. But if you're sticking to the methodology, it's a godsend. All other frameworks pale in comparison to Spring, which is why it's as popular as is is. It can seem daunting in the beginning, but I've learned to love it and I work with it every day. Also, Spring never generates source code, at no point in time. It works based on the extensive use of reflection and dynamic proxies. Spring Data generates some bytecode at runtime, but you'll never see it. And no matter what you do in Spring, there's always some sort of escape hatch which you can use to do things "your way" if needed. You know what's "weird and wrong"? Async.
Прихожу домой, вижу у тебя новый видос вышел) сразу бросил все дела и погнал смотреть) оно того как обычно стоило
Found this when I have been having problems with Spring security 😢. Bruuuh….
I can understand where you're coming from, but I'd argue that the domain layer is far more important than the data access layer in most cases. You can fiddle around with query optimizations all you want, but unless you have a product that is actually available and in demand, you won't be making any money.
Also, if you have a query that is taking 30 seconds to return, then you've done something horribly wrong farther up the call chain. At that point, it's not Spring's fault.
In my experience, I've never had a Spring query take anywhere close to 30 seconds. In this day and age, there are enough concurrency solutions available in the JVM and Spring if blocking calls are really a concern.
I'm of the opinion that most of your time should be spent on the domain, and the infrastructure around it should be good enough that end users won't complain, and obvious costs aren't being accrued, but hyper optimizing your infrastructure so that not a single millisecond is wasted has seriously diminishing returns.
Well that's why they call it opinionated.
That is what happens when you come from a Python background with Junior level experience. 😅
I think you should listen less to tech youtubers and catchphrases like "magic is bad", "abstraction is bad" or "simplicity is better than complexity" and try to understand why people are actually using what they are using, why they invented these things and just that, criticize these things while providing alternative and good solutions to the problems these things were created to solve. This is what will make you a good engineer, and not "learning HTPP and SQL".
Totally. This is just another engineer being an engineer who doesn't understand business needs and not thinking about why it was created.
how does learning Spring's abstraction make me a better engineer than learning HTTP or SQL. My time learning how Spring works will be mostly rendered useless if I have to use new framework or something else.
@@yellomango_6440that's part of being an engineer my friend. You need to know both, the basics to know what the abstractions are doing, and the framework to build fast so the business is profitable and you can keep your job ;) why do you think most startups are using the JavaScript (craziness) full stack?
@@yellomango_6440
Because ex nihilo nihil fit, if something exists there is a parallel between this given thing and the others that already exist. If you learn Spring you will absolutely transfer this knowledge to the next framework you use (and even when learning HTTP and SQL you will understand why they made some design choices if you mastered them). It is the same principle as learning a language or a library, knowledge is generally transfeerable. And you can absolutely learn both (Spring and the principles).
@@yellomango_6440 No, in the same way that learning C or Java is not useless when you later learn Rust or Go. The experience with other languages and frameworks helps you learn new ones faster as you are already familiar with the concepts involved and just need to learn the differences rather than everything from scratch.
In most jobs you'll have, knowing the frameworks well is more useful than the nitty-gritty details of HTTP or SQL. You'll need to know the basics, but you don't need to be able to write a SQL parser or implement your own HTTP server. Those exist already and you're far better off using one that someone else wrote that thousands or millions of other developers use and have tested to make sure it works. Focus on the business logic and the tools you need for that.
People in the comments don't seem to understand that learning spring/hibernate/any annotation driven framework is an experience that requires you to strictly read documentation(official or not) for EVERYTHING you need to implement/change(and if you can't find in the docs an answer for a problem you have then good f-ng luck), as reading the source code and command clicking/debugging to figure out what's going on is pretty much impossible. A side effect of this annotation driven experience is that it's thrown into the garbage bin once you move to different tech stack (go, kotlin with ktor, rust, idk what else). That shouldn't be the case. It's not normal. You shouldn't have to learn a framework with its own rules which you can't figure out by yourself, isn't intuitive and the experience helps you very little once you move. Worked with spring once, hard pass since then. Agreed with many people that say hibernate is even worse.
spring is a framework that in a long run, will force you to read what code a spring developer has written. For learning, its a boon but when stuck on an actual prod issue and you need a quicksolve, it will definetely give you headaches.
Still remember an issue where our client gave us an api which had request body in GET request method. Python can easily invoke such apis but to no surprise, Java can't. Reaching to this conclusion took hrs of debugging😅.
When your application doesnt start simply because you missed an annotation, where no error message ka point out towards which annotation is missing is a different level of nightmare.
Also things start to get quite interesting when you learn how the injections are actually powered😂hint: reflections😉
I've been working with java and spring since 2014 and got certified, I think spring will still be there. But, in my new project I replace spring security with keycloak, spring cloud with linkerd/istio, then I need my application more lightweight and i see kotlin and ktor working good together, I try it and I enjoy it.
Agree 100%. Switch to Go ecosystem and never feel happier.
Dependency Legos does not sound very fun, but Dependency Jenga is a real thrill, especially when playing it in a production environment.
And Qt is the best one. Excellent design, superb documentation.
I tried Java and Spring being too magic put me off. (I know that is apples to pears, but the reason I wanted to learn Java was because of all the jobs wanting Spring)
What on earth is spring?
You speak wisdom.
You can also use Spring without annotations, but that’s definitely not the common usage of the framework you’ll see in the real world. Reducing the magic in Spring helps, but it takes effort.
"except maybe Ruby on Rails" sbd call the police, there's been a murder
The WHOLE of modern Java have these issues. Try reading json from an API with valid JSON, which transmits text/json rather than application/json
what is the best framework ever created in your opinion?
Use Spring. Thousands of Spring devs can't be wrong. 🙃
Spring offers you the flexibility to not worry about the http or you directly deal the http request and response
Just read about spring boot little more before the video
I think what make Spring hard to use, is it approach to use classpath scanning to bind the code, instead of using pure Java. It make Spring application lose its strength in static type, and turn into a hard to read mess. It make Spring no longer Java.
It seems like bloat and indirection begets bloat and indirection. Spring is all about insulating you from all the underlying technology, but every commercial Spring project I've worked has had tons of custom abstractions for insulating you from Spring itself. So you are not only actively discouraged from learning and leveraging HTTP and SQL, you're even discouraged from learning and leveraging Spring itself.
I didn't know about Spring in particular but I definitely agree that putting a lot of abstractions around rather simple concepts makes no sense.
It might be easier to write code without understanding what's beneath but debugging all of that can be almost impossible in some cases.
Looking at the comments, Im so glad I'm not the only Spring hater.
10:37 I use clean architecture, no service layer required.
Thank you for sharing it I thoughts I was the only one who thought spring did magic which didn’t make sense at all I am not alone the same thing
I quit my job because of Spring. The annotations we're making me go crazy
Skill issue
Spring is good actually, but the memory...
For me the worst thing spring incentivises is pushing your domain model to be your database model. This is really bad.
I know I shouldn't, but I have to comment....
I actually use spring in production and I do have a good understanding of all the concepts.
I my observation hibernate does a pretty good job of writing performant queries and sometimes it is way better than I am.
I could deal with everything if I wanted. But I have to say, that spring is a solid and fast tool that gets me readable code that everyone in my team can understand and reason about.
I would be using dependency injection anyways, so it is nice to have it inside my framework. My focus is make it work fast and don't spend time on solving problems that someone else already solved.
If I wanted to do everything myself I would use rust or C and not Java. Just think about all the waste that is in the Java standard library that you won't be using 99.9% of the time.
Java itself is inherently full of magic and shit I have no control over like class loading, garbage collection, preferences, introspection. By this logic you should avoid using Java and kotlin altogether and ant try macro assembly or maybe the language without a standard library (rust)...
Even if my comment is meant to be provocative I don't mean I'll to anyone.
If it was that bad nobody would be using it. In my practical experience most problems I find with spring is me not reading the manual and just winging shit I should have researched beforehand.
I thought it's click-bait. Any framework works like that, else you end up developing new one for you.
Complex enterprise applications need complex frameworks which you usually don't fully understand in 6 months.
All your points are valid from junior point of view, but when you are working on enterprise level, you well how spring get it right.
Nice you don't need to use someone else code, you're welcome to implement your http client in Assembly, by the way, you don't use Autowired, read the docs!!
so enterprise applications are written by people that don't fully understand them nor the tools used? Sounds about right as an IT admin.
Spring doesn't really do that much for complex enterprise applications either. Nothing is worse than being a junior developer and trying to run your application and getting a huge, opaque error from some abstract factory, googling it, and getting no responses. With the other libraries and frameworks I've used, I can press CTRL-B to instantly see the implementation and look at what might be going wrong, I can attach a debugger and know where to put breakpoints. With Spring, you have some 30+ frames of reflective access that's basically impossible to navigate.
Well I'm glad I never continued to learn Java after university
11:17 man you could not have worded it better
hopefully I never see a "Asp NET core is the worst framework ever created"