Open fgm opened 5 years ago
Not sure which enhancements this would bring exactly. We already have a method sender, and Meteor methods can be called asynchronously ?
MethodSender is available when the target server happens to also be the server for the client app. In some cases, like mentiond by @arggh one may want a central server for multiple Meteor apps, and not be able to use it. In these cases, the Beacon API would be an improvement over the current Ajax calls.
Also, I suspect that not having any kind of waiting being performed, even in the "background" might be faster than the Meteor method call.
Multiple meteor apps : a method-based sender can still support that, a client can set ddp connections and send method calls to different Meteor servers ?
From what I (brielfy) read, I thought the Beacon API was mostly useful for sending data at unload time, where async ajax is not doable (not sure about websockets though). So like mostly for analytics.
So the use case is for logging data when a user leaves the page ?
That's one possible use, but the main use I read about was more generally for sending information without awaiting any acknowledgment (à la early MongoDB), one case for which would be nonessential logging.
For a few examples: https://www.smashingmagazine.com/2018/07/logging-activity-web-beacon-api/
The Beacon API allows sending data without waiting for the result, which is often what is expected from front-end logging, to minimize impact on user interactions.