Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Angular reactive http #4

Open
arcturuscom opened this issue Mar 9, 2021 · 4 comments
Open

Angular reactive http #4

arcturuscom opened this issue Mar 9, 2021 · 4 comments
Assignees
Labels

Comments

@arcturuscom
Copy link

Hello, I would like to contact you concerning your idea about that angular doing http calls on blocking mode if we are not using sse.
I'm not agree. Both are reactive, the difference is that sse stream whenever an item available.

Could you correct me if i'm wrong?

@mechero mechero self-assigned this Mar 9, 2021
@mechero
Copy link
Owner

mechero commented Mar 9, 2021

I'm not sure if I understand your question, but let me try to answer. You can implement reactive programming on the Angular side but, as long as the backend works with blocking calls, you won't see the advantages.

You could say it's reactive if "reactive" in this scope means reactive programming.

@arcturuscom
Copy link
Author

i'm totally agree with your answer, we will not see advantages as long as the backend works with blocking calls.
this is not what i've said, what i had tried to say is that if your backend works with reactive non blocking IO ( Netty server for exemple) then angular also will receive response on observable and then we wll have a full reactive Non blocking IO in this case whitout even using SSE

i think you defined the reactive calls by doing it with SSE, i would say no, because if you have 2 http endpoins that some of them doing a reactive non blocking IO and the other based on SSE, the both doing reactive responses the only difference is that SSE calls will stream the elements as long as they are ready but on the other call data will not be streamed but still reactive

@mechero
Copy link
Owner

mechero commented Apr 3, 2021

then we wll have a full reactive Non blocking IO in this case whitout even using SSE

This is right in theory, but in practice, there is no other way afaik to serialize objects and make them available to the client in a non-blocking way in Spring. You could probably create your own way (more low level) to send these objects to the client. Maybe there is even a way to override the JSON serialization so it sends JSON chunks instead of waiting for all the data to serialize it. But again, in practice, with the tech stack used in this guide, it's either JSON (blocking) or SSE (non-blocking).

If you find a way to make your client read the response from Spring in a non-blocking way without using SSE please share the snippet, I'm happy to correct/extend this use case 😄

Anyways, I think I'll clarify the part where I stated that in the guide since you're right there, it's not really angular doing that. Could you please point me to that?

@arcturuscom
Copy link
Author

but in practice, there is no other way afaik to serialize objects and make them available to the client in a non-blocking way in Spring

what do you mean with make them available to the client in a non-blocking way ? yes Json serialization is a blocking operation but the EventLoop that handles the request is not blocking, the eventLoop will still handle requests while the JSON response still in process.
You right about your idea how JSON serialized objects to the client but in reality the eventLoop thread still handling requests.

If you find a way to make your client read the response from Spring in a non-blocking way without using SSE please share the snippet, I'm happy to correct/extend this use case

this is possible in Micronaut for example : https://docs.micronaut.io/latest/guide/#clientStreaming
i don't know about spring since i left the framework 2 last years ago but i think yes it's possible since Spring and Micronaut are both similar.

SSE comes with advantages when you want to stream a large Json objects, but if we talk about a response with 1 simple JSON object with a few fields then there will no difference between the both strategies

Anyway i would like if we could chat in live about this subject, it's really interessting and it's could be a good chance to learn from each other :)

you can reach me at : [email protected]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants