@dontstealecorock said in Client v1.6.0:
I think u can try better. I dont mind if you will be rude(actually your last post is toxic so whats the difference) There should be a reason for switch to non blocking approach so just write it. Maybe u can share perfomance numbers. How many memory blocking code was consuming per call?
Ok, so here you go:
You take the time to spit out unqualified critics on a topic by reading a short summary of the changes obviously without a) even have the slightest understanding what reactive is about or b) how it affects the client architecture overall. Furthermore if you would have reviewed the changes you would have spotted that this change goes beyond just introducing reactive patterns.
Less memory consumption due to less threads is one of many benefits, but it is not the main driver behind moving to reactive patterns.
I will not argue that in general replacing classic synchronous blocking code with reactive code is increasing the code complexity. I have seen it. I work with it every day. And in some cases it's worth it and in others it's not and I would not introduce it without good arguments.
But that "reactive is complex"-bashing you do here doesn't apply at all, because the client already tries to be asynchronous by applying the crappy Java 8 CompletableFuture logic everywhere it touches API calls. This code was already pretty ugly and complex to understand and using Project Reactor actually can make the code more consistent and easier to read. It also allows additional improvements such as better unit test supports and better handling and mixing of separate async operations than the Java 8 library can.
Looking at actual lobby-server tcp connection: reactive programming here allows us to move away from a constantly polling io thread which eats a lot of CPU waiting (RAM is almost completely irrelevant here). But again this refactoring brought along some other changes and Sheikah can't mention them all along.
We split off the lobby protocol into a dedicated module and wrote it in Kotlin which results in much fewer code. We now have protocol mesage classes with correct null/not-null annotations which makes it easier for future developers to work with it. We tried to decouple the lobby protocol from the client state so we can adapt to protocol changes more easily also enhancing the overall architecture.
Soo essentially we did these changes for different kind of reasons.
You cannot know these reasons. That's completely fine. You can ask for it though and we'd be glad to explain them within our time constraints.
But just picking one argument and bashing on it is just buzzword trolling.