Create UnifiedPush UML diagrams #37
Conversation
mitchdowney
changed the title
There was a problem hiding this comment.
I'm not sure how important the Podverse web app is, but you might want to check out WebPush. UnifiedPush is a superset of WebPush, and all the same concepts apply.
If you support WebPush (again, subset of UP), you can receive notifications in both Web and Mobile clients.
| MobileApp -> User : prompts the user that notifications are a \npremium-only feature and to please login | ||
| User -> MobileApp : user logs in, and tries to subscribe \nto notifications for a podcast again | ||
| MobileApp -> User : shows the UnifiedPush setup modal | ||
| User -> MobileApp : inputs their UP endpoint hostname \nand presses the Register button |
There was a problem hiding this comment.
This is not User->MobileApp. The app calls the UnifiedPush library, UnifiedPush.registerApp() and the UnifiedPush library replies with the endpoint automatically in a call to onNewEndpoint() - https://unifiedpush.org/developers/android/#register-for-push
There was a problem hiding this comment.
User -> MobileApp : selects distributor if many are available on the device
MobileApp -> UPMobileApp : asks for an UP endpoint
UPMobileApp -> MobileApp : sends the UP endpoint
MobileApp -> API : sends the UP endpoint
| User -> MobileApp : inputs their UP endpoint hostname \nand presses the Register button | ||
| MobileApp -> API : sends UP hostname in \nan authenticated request | ||
| API -> API : creates UP salted_topic_id | ||
| API -> Postgres : saves the UP hostname+salted_topic_id \nwith ManyToOne to User table \nin the unifiedPushToken table |
There was a problem hiding this comment.
And the API doesn't create the topic, the app receives it from the distributor, and it uses that topic. You have to treat the hostname+topic as one single URL, they're not separable.
There was a problem hiding this comment.
@karmanyaahm (still learning)
Podverse would be required to each notifications to each and every hostname+topic
How would this properly scale?
What are the scaling limits?
Would/could we be blocked by a commonly used U.P. server?
There was a problem hiding this comment.
If you need to, you can use "instances" during (MobileApp -> Distributor) registration to have an endpoint per subject. You can also get a single endpoint for the app and push a content that will help to identify the podcast subject
There was a problem hiding this comment.
How would this properly scale?
What are the scaling limits?
Would/could we be blocked by a commonly used U.P. server?
- Matrix servers send hundreds of messages per device per day, and we have fixed most rate limiting problems.
- Performance-wise, it shouldn't be a big deal because of connection reuse - as long as the requests are batched properly, node (or another runtime) should automatically send all the HTTP requests over one connection.
- Also, WebPush, the standard for push notifications to web browsers, uses the exact same model (unique endpoint for each device) and all services that push to web browsers use it.
| UPServer -> NtfyMobileApp : pushes notification | ||
| NtfyMobileApp -> User : displays notification | ||
| User -> MobileApp : taps notification\nto open Podverse |
There was a problem hiding this comment.
| UPServer -> NtfyMobileApp : pushes notification | |
| NtfyMobileApp -> User : displays notification | |
| User -> MobileApp : taps notification\nto open Podverse | |
| UPServer -> NtfyMobileApp : pushes notification | |
| NtfyMobileApp -> MobileApp : forwards notification | |
| MobileApp -> User: displays notification | |
| User -> MobileApp : taps notification\nto open Podverse |
No description provided.