Nice feature and good explanation. May be Spring team should extract webClient into separate module and it's own dependency, so we no need bring entire webflux.
This is awesome. They should also implement java "Optional" as a possible return type on the interface. So we can do something like "todoClient.get(4L).orElseThrow(...)"
Hi, I would still its bit cumbersome compare to feign client. With Feign client we can declare, annotate and Enable it. Why new http client is not like Open Feign client ? Just curious. Thanks a lot for sharing all the knowledge and I learnt so much from your videoes.
Feign client is definitely more mature. I have no answer for your question but I am looking forward how it evolves. There's still quite a bit of time till 6.0 goes GA. Thanks for feedback!
So glad I found your channel! You're a good teacher and helped me understand Spring a lot better and became a little better at my job with your explanations. Thanks man!
Yes it is indeed same concept to Retrofit and Feign. More about declarative clients in recent talk from Spring IO conference: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-5LNOnVJKW_4.html
Btw. is the WebClient required for creating the factory? In the past we had big issues with it when using blocking mode and multithreaded and moved back to RestTemplate to solve it.
Great video, this is very similar to various http clients like resteasy. Will the annotations like @Path, @Get, @Produces, etc will be compatible with this feature of Spring 6 ?
Nice. I hope it will be a great replacement for feign clients. I also interested in load balanced implementation, but more likely it will be described in documentation.
I started using feign client knowing that i could override the URL instead of using serviced. I hope the advantage over feign client is the easier upgrade on each spring boot version and integrations with the spring ecosystem
Yes, the idea is the same, just native to the framework. I guess it makes it easier for Spring to keep it compatible with spring native and all the observability tools planned for 6.0
Not dumb at all! Same concept but built into the framework. I think it will be easier to keep it aligned with Spring Native and observability coming in Spring Framework 6.
@@Marcot348 in spring world, to get proper logging, metrics and traces you should go with RestTemplate or WebClient. Only if you don't need any of these Java built in http client is fine
The most important one is support for reactive types. Other than that, since it is baked into the framework, we can expect better compatibility with all the other framework features, like AOT, logging, tracing, metrics.
I hate it!.. Don't get me wrong, the video is great, the explanation is awesome. But the subject... most of this autogeneration, autoconfiguration, autoeverything... it doesn't actually increase speed of new features delivery to production and it doesn't reduce number of bugs that people make along the process. In my opinion this sort of autogeneration just adds tens of thousands lines of codes with very little value. And of course I understand developers who work hard to deliver such a feature into spring - it's cool. And I agree with this. It is indeed cool to work on it. But nevertheless, it does more harm, than value, when used as a tool.
I can understand the sentiment - I wasn't a big fan of Feign, hope this will work better and more predictable. Luckily lower level clients are not going anywhere so there will be a different level of abstraction for everyone. Thanks for feedback and your thoughts!
Its disappointing they have gone this way . Because it will be much better to provide controller interface. I know there is another tool for this, but expected something like this from spring team.
Nice... but interestingly Java is still too much verbose for so simple things that you can write in way less lines of codes to do even more. Amazing! Well, at least it's improving.
I agree, but still think that Java verbosity is a feature in a sense. I work in a big corp with code that has been running in Prod for more than 20 years, if that code wasn't verbose enough, it would be almost impossible for new programmers to understand what's happening in it 😅
Java is indeed verbose but it's not necessarily a bad thing. Records is a very good step forward, but ideally we would get rid of more regular boilerplate.
@@SpringAcademy I understand, but let's agree to disagree, shall we? Because, in a practical point of view, in fact it is a bad thing: the more you write *unecessary* code, the highest the cost to maintain it later and also the highest the probability of bugs will be. So, if you can remove these unecessary code (that is there just to be verbose the way Java likes to be), why not?
@@panthonyy I understand what you say and I totally agree, but that's not what I am talking about. Notice that I was mentionning *unecessary* code that could be removed by a simple and more well-designed framework architecture (like many others that are popular in other languages) that balances the use of convention and the explicit code you still have to write. But I believe that would go against the Java-nature of things, that is to write, write, write and more write (instead of just 4.times("write")). :-) Greetings!
Just watching 30 seconds midt way through the video, and all im thinking is yet another "magic" abstraction to do very simple and basic things to a magic trick. Creating http-controllers/routers is one of the most basic things, why the hell do we need http interfaces. I swear to god these engineers keep adding shit to their libraries just cause they got nothing real to do.
@@panthonyy It is not simplyfying anything. It creates a new pattern of complexity and new pages of documentation. No there is a new way of doing the same shit, what is good about that?
