Overview
PulseGrid manages audiences, queues, delivery safety, usage limits and delivery history. Firebase Cloud Messaging (FCM) performs the final delivery to the user's browser, Android device or iPhone.
The Firebase project belongs to the website or mobile app receiving notifications. A token generated by Firebase project A cannot normally be sent through unrelated Firebase project B. PulseGrid therefore stores one server-side Firebase connection for each PulseGrid project that uses Push.
There are two different Firebase values:
- Client Firebase configuration: public identifiers used by the website/mobile app to request permission and obtain a device token.
- Service-account JSON: private server credential used only by PulseGrid to send through FCM.
Never place the service-account JSON in browser or mobile code.
Setup
Complete flow:
1. The developer creates or selects the Firebase project used by the application.
2. The application integrates the Firebase client SDK.
3. A visitor grants notification permission.
4. Firebase returns an FCM registration token for that installation.
5. The application's trusted backend registers the token with PulseGrid.
6. PulseGrid stores the device under the matching PulseGrid project.
7. A notification is created through the dashboard or API.
8. PulseGrid claims and queues the notification once.
9. The worker sends it through the saved Firebase service account.
10. FCM delivers it to the opted-in device.
Code example
Website or mobile app
|
| Firebase client SDK creates FCM token
v
Trusted application backend
|
| POST /api/push/devices/register/
v
PulseGrid project -> queued notification -> Firebase FCM -> opted-in device
Notes
One notification sent to 200 devices consumes 200 device deliveries. The PulseGrid dashboard does not need to remain open because dispatch runs server-side through Celery. In production, run Django/Daphne, Redis, a Celery worker and Celery Beat.