my question is when you run the ClientApplication how the program run into the Function rSocketRequester()? or because you used ApplicationReadyEvent so the function client() will run ? thank you
I understand that the bidirectional rsocket channel is something we cannot achieve with http based service, but request - stream paradigm is still supported if we have return type as octet/stream so the server returns a flux of events. Correct me if I am wrong.
Yep, you enable chunked encoding and return many messages. But there are some subtle problems with that. I worked with such code and do not recommend it.
@@ImaskarDono naa.. no need for chunk encoding. Just put "produces" header as octet/stream and then write to output stream as much and as frequently as you want (obviously constraint by configured timeouts) and you're good
Well, why not stick to old BBS messaging system instead of inventing TH-cam comments section? "Reinventing the wheel" means innovation and keeping human's brain warm. If we don't do it anymore, soon enough we won't even be able to think.
rSocket may be nice but it uses reactive to configure and run the service layer. Why would anyone want to configure and instance the service layer over and over again in a reactive manner? Just absurd.
I don't really see where the revolution-ary part is. Is it so different than just using GRPC endpoint? Or on the other extreme, just using spring-reactive and have a http endpoint? The idea that you can choose between TCP/Aeron alternative is bullshit. I've seen it advertised as interchangeable since 1 year ago, truth is not even today I've seen any Aeron implementation.
It's different than gRPC in that it isn't based on HTTP2 and it doesn't require google protocol buffs for payloads. RSocket can run on things like Aeron and TCP and WebSockets, not just TCP like HTTP2. See rsocket.io/docs/FAQ.html for answers to some questions like "Why not...". Also, the fact that it can run on WebSockets/Aeron/TCP (vs just TCP) isn't BS. Some of the largest websites on the planet use RSocket + WS at scale. I haven't used the Aerson implementation but I have no reason to doubt that it's there for a reason. And for that matter, I have no reason to doubt that it's an awesome choice given how powerful Aeron is. I hope these answers help, and next time, please do your best to pose interesting questions without resorting to the vulgarities, eh? I'm certainly no saint but I try to do better on the Spring YT channel because younger people sometimes watch these tech videos... thanks.
@@coffeesoftware Hi, I meant more if it's throughput performance you want, you'd go for gRPC but you'd deal with protobufs, yes. If it's JSON you plan on transfering, the current spring-reactor is probably sufficient. WS endpoint is covered as well in "traditional" spring-reactor. There is probably some performance to go with tcp that you'd not have in spring-reactive, for not having to deal with http headers. I don't want my comment to appear as inconsiderate of the work, I'm just missing the 'revolutionary' spark. I still didn't find the Aeron implementation - I was expecting it on some kind of aeron-transport module github.com/rsocket/rsocket-java, or in the examples github.com/rsocket/rsocket-java/tree/master/rsocket-examples/src/main/java/io/rsocket/examples/transport
@@MrSpamTrapper I can actually attest to using RSocket as a unified HTTP/S and Websockets server. In our case, we have legacy hardware platforms and customers to support that cannot speak a modern version of TLS, but the demand from mobile customers has pretty much necessitated having HTTP2 support. We don't have the luxury of a microservices platform, so the solution has to fit both use cases. For now, we can leverage Websockets on the legacy hardware platforms to get around having to split the production environment, but we are looking at Aeron and Google QUIC (HTTP(3) over UDP) support in RSocket as a way to cover both legacy and current hardware along with the mobile clients with minimal resources and de-duplication of code. It just comes down to "if" we can fit the needed network stack components in the legacy systems' memory. I will admit the use case where you'd have HTTP AND a non-TCP endpoint on the same system--speaking two very different protocols--is niche, but think about all of the embedded systems out in the wild that have to stay hardened against bad actors on the net.
The more I learn the less I know. SMH! This rings true for me every time I watch one of these videos. Great content Josh. Thanks.
Great Content Josh, thanks for sharing, i'm always hearing spring bootiful podcast.
Very good! I just wanna add the maybe would be better to not use var on presentations, that way we can see the types. Congratulations
awesome command of the IDE -> jealous!
fun fact: his Chinese character name actually means dragon's gonads in Cantonese
Great videa. Thanks Josh.
Thanks josh long, i learning rsocket, spring ... in your contents
Thanks for your great video.
my question is when you run the ClientApplication how the program run into the Function rSocketRequester()? or because you used ApplicationReadyEvent so the function client() will run ? thank you
ni hao Josh, I can learn new things per sec in your talk (dev environ, Spring integration, RSocket, Reactive, etc) . Going to get your book on leanpub
Josh, can you expand imports in videos? It's important to understanding, which API you are using now. E.g. Files in this video.
Thanks for your informative video.
Thanks josh, good content!
I understand that the bidirectional rsocket channel is something we cannot achieve with http based service, but request - stream paradigm is still supported if we have return type as octet/stream so the server returns a flux of events. Correct me if I am wrong.
Yep, you enable chunked encoding and return many messages. But there are some subtle problems with that. I worked with such code and do not recommend it.
@@ImaskarDono naa.. no need for chunk encoding. Just put "produces" header as octet/stream and then write to output stream as much and as frequently as you want (obviously constraint by configured timeouts) and you're good
@@Sagar13iffy spring will set it for you automatically, I just wrote how it works on the protocol level.
@@ImaskarDono ahh I see.. I too have such a code running in production. Didn't face any issue yet. Why do you not recommend it?
@@Sagar13iffy can't detect connection problems, exchange may get stuck forever.
This make me remember of tcp/ip connections. Why everybody is reinventing the wheel ???
RSocket can *use* tcp/ip connections, it is an alternative to the HTTP protocol (application level, not transport level).
Well, why not stick to old BBS messaging system instead of inventing TH-cam comments section?
"Reinventing the wheel" means innovation and keeping human's brain warm. If we don't do it anymore, soon enough we won't even be able to think.
rSocket may be nice but it uses reactive to configure and run the service layer. Why would anyone want to configure and instance the service layer over and over again in a reactive manner? Just absurd.
why not?
Was the typing recorded in real speed? Man, this is badass productive coding!
Jealous :-(
Off the topic but anyone has link for initial instrumental music.
The biggest problem is: the golang version and js version is still not usable
for rsocket?
what are you talking about? this framework is for java
Go java ;-) and that biggest problem of yours is solved like magic!
awesome video, but sometimes I can catch some GTA sounds from the background. Am I right? :)
Ni hao?
wow
I don't really see where the revolution-ary part is. Is it so different than just using GRPC endpoint? Or on the other extreme, just using spring-reactive and have a http endpoint? The idea that you can choose between TCP/Aeron alternative is bullshit. I've seen it advertised as interchangeable since 1 year ago, truth is not even today I've seen any Aeron implementation.
It's different than gRPC in that it isn't based on HTTP2 and it doesn't require google protocol buffs for payloads. RSocket can run on things like Aeron and TCP and WebSockets, not just TCP like HTTP2. See rsocket.io/docs/FAQ.html for answers to some questions like "Why not...". Also, the fact that it can run on WebSockets/Aeron/TCP (vs just TCP) isn't BS. Some of the largest websites on the planet use RSocket + WS at scale. I haven't used the Aerson implementation but I have no reason to doubt that it's there for a reason. And for that matter, I have no reason to doubt that it's an awesome choice given how powerful Aeron is.
I hope these answers help, and next time, please do your best to pose interesting questions without resorting to the vulgarities, eh? I'm certainly no saint but I try to do better on the Spring YT channel because younger people sometimes watch these tech videos... thanks.
@@coffeesoftware Hi, I meant more if it's throughput performance you want, you'd go for gRPC but you'd deal with protobufs, yes. If it's JSON you plan on transfering, the current spring-reactor is probably sufficient. WS endpoint is covered as well in "traditional" spring-reactor. There is probably some performance to go with tcp that you'd not have in spring-reactive, for not having to deal with http headers. I don't want my comment to appear as inconsiderate of the work, I'm just missing the 'revolutionary' spark. I still didn't find the Aeron implementation - I was expecting it on some kind of aeron-transport module github.com/rsocket/rsocket-java, or in the examples github.com/rsocket/rsocket-java/tree/master/rsocket-examples/src/main/java/io/rsocket/examples/transport
@@MrSpamTrapper I can actually attest to using RSocket as a unified HTTP/S and Websockets server.
In our case, we have legacy hardware platforms and customers to support that cannot speak a modern version of TLS, but the demand from mobile customers has pretty much necessitated having HTTP2 support. We don't have the luxury of a microservices platform, so the solution has to fit both use cases. For now, we can leverage Websockets on the legacy hardware platforms to get around having to split the production environment, but we are looking at Aeron and Google QUIC (HTTP(3) over UDP) support in RSocket as a way to cover both legacy and current hardware along with the mobile clients with minimal resources and de-duplication of code. It just comes down to "if" we can fit the needed network stack components in the legacy systems' memory.
I will admit the use case where you'd have HTTP AND a non-TCP endpoint on the same system--speaking two very different protocols--is niche, but think about all of the embedded systems out in the wild that have to stay hardened against bad actors on the net.
阿里巴巴面试
不明白