PubSub aggregated change event

[yk2081]

Hello again,

Will it be possible to emit a single event for create, upsert or delete ( any change in DB ) so I can have a single method in the client to refresh the objects?
Or is there a better way to handle this?

Thank you,

PS : Additionally, I cannot catch delete event because it requires a specific ID.

[jonathan-casarrubias]

@yk2081 Are you asking to listen just 1 event to any change in the Model?

[yk2081]

Thank you for your prompt response @jonathan-casarrubias

Let's just say we want to display a list of items.
Previously, I just reissued a GET method whenever user adds/updates/deletes an item in order to reflect the latest state of items in DB ( Because there are other users changing the same list ).
I also used 'timeout' methods to periodically refresh the list.

Now that I have the power of real-time events thanks to your library, I am wondering what would be the best way to achieve the same end result.
As of now, it seems I will need to listen for each event ( create, upsert, delete - needs an id ) in order to issue a refresh.
If there is one event for any change in the Model, I can simply listen for that event and issue a refresh.

Additional Related Questions :

1. Why did you decide to go with socket.io instead of EventSource when Loopback already has create-stream methods available? Is it because of the browser compatibility issue or the same domain limit?

2. In your blog, you mentioned do not add an extra service layer for APIs. Is it because of the increased complexity or will it actually cause an issue? I am asking because I need service layers for other shared methods and wanted to wrap the APIs inside the services for the sake of consistency.

3. In your opinion, what would be the best way to handle an app-wide Model that needs to be synced? Assuming I am using ngrx to save the state of this Model, one way is to listen for events in the AppComponent so the connection is persistent even if the user navigates to different pages. Another way is to listen for events in the children components where needed and disconnect when not needed. Since the second approach is more cumbersome, will it be a too much waste if I listen for events for ALL Models in the AppComponent? ( Since there will be only one connection )

4. I am already using ngrx with your library and it's working great. It looks like ngrx integration is in your TODO list and just wondering what you wish to accomplish.

I apologize for the long post but I wish to learn more about your project.
Thank you again for your time and effort!

[jonathan-casarrubias]

@yk2081 I now understand your use case, I think I can add support for something similar to the EventSource that leads me to your next question.

1.- I did not decide to go using EventSource because this is a cross platform SDK, it means it can run not only browser environments, but in native environments... So, I tried to implement the most global transport that is WebSockets, it can run in native apps and in the browser, remember this SDK also work for native applications using NativeScript 2, so It is not just because of the lack of browser support for the EventSource but for the entire scope of the module, but maybe in a future when is more mature I can add support for EventSource.

2.- You should avoid to add extra layers for multiple reasons:

a) It will add complexity and will create an unnecessary foot print in size and processes, if you run into a situation that you need to wrap up multiple microservices into 1, you must do that from the BackEnd by creating a RemoteMethod, this way the SDK Builder will automatically create a method for your clients to use this wrap service.

b) If you wrap in the back end, you will also avoid a huge network traffic because of the multiple HTTP Request you are making, it will drastically increase the performance of your app, it is just better to make 1 request... Avoid network floods and IO Blocking by letting the backend to handle the wrapping is just faster

c) Also if you need to add custom logic to the client model instances, you can do it by extending any model and adding new functionality then you can share logic between all of your model instances in your client side. That is documented in the Angular2-Docs in the root of this repository.

3.- You should only use real-time event listeners where you need it, if it is a listener that needs to be app wide, e.g. a notifications model, you need to be listening a notification no matter what section of your app is active, then you can add that to the AppComponent for sure, but please don't add everything within the AppComponent just to avoid multiple connections. Why? Because I already addressed that issue, so the socket connection is made only once, and then is returned as a singleton connection, so every listener you set is using the same connection without disconnections or reconnections while navigating through different sections/components.

5.- Honestly I don't know, that actually is a community request and I will evaluate it when is the proper moment, at this moment the milestone is to fix any bug found by the community in order to release the version 2.0.0-stable, then there are already some top priority features for the 2.1.0-beta versions, which should include Angular Universal, NgRX Support if needed and I'm pretty sure I will address this issue in version 2.1.0-beta.X

No worries I love community feedback and collaboration, please stay connected.

Cheers!!!
Jon

[jonathan-casarrubias]

@yk2081 good news, the first implementation for EventSource support is coming in version 2.0.4.

[dmastag]

Awesome, just finished trying this out with the 2.0.4 release. And got Create, Update and Remove working flawlessly.

2 Questions though:

1. You said this is the first implementation, what else would be implemented into this?
2. Just asking to confirm from my other question, this would work on a nginx with multi cluster configuration, right ?

Thanks
Julian

[jonathan-casarrubias]

Hi @dmastag is great to see it just worked right away

Let me try answer your questions

1.- I say is the first implementation because I wanted to provide it right away, but I feel it needs to be refactored as well as other parts of the builder, I'm not necessary talking about the generated SDK, but in the way it is generated, Also right now is not sending the AccessToken so if you block the endpoint with an ACL you won't be able to use it.

2.- In this approach I'm honestly don't know how would scale, we will need to verify because I have read a considerable amount of information about server-sent-events including the official specs and I don't see anyone discussing its scalability. Since the browser is the one managing the connection it may be possible that through a load balancer it just get the messages.

But to be honest I have never used in production enviroments as I did with the PubSub pattern and the loopback-component-pubsub in which I can confirm it does work in clustering environments thanks to socket.io adapters for clustering.

So all of these are my reasons to specify that this is the first implementation, modifications in multiple areas may be done, when more tests are done and feedback is received.

Cheers!!
Jon