Overview
PulseGrid manages Push audiences, device registrations, queueing, idempotency, limits and delivery history. Firebase Cloud Messaging (FCM) performs the final delivery to web, Android and iOS applications.
The Firebase project belongs to the application receiving notifications. PulseGrid stores a trusted Firebase service-account connection for the matching PulseGrid project.
Two Firebase credential types must not be confused:
- Firebase client configuration: public configuration used by the website/mobile app to obtain an FCM token.
- Service-account JSON: private server credential used by PulseGrid to send through Firebase Admin/FCM.
Never put the service-account JSON or PulseGrid secret key in browser/mobile code.
Setup
Complete flow:
1. Configure Firebase in the website or mobile app.
2. The user grants notification permission.
3. Firebase returns an FCM registration token for that installation.
4. The app sends that token to its own trusted backend.
5. The backend registers the device with PulseGrid using the official Node or Python SDK.
6. PulseGrid stores the device under the correct project.
7. The backend or PulseGrid dashboard creates a notification.
8. PulseGrid queues it and the worker sends through the saved Firebase service account.
9. FCM delivers it to the opted-in device.
10. PulseGrid records delivery state and monthly usage.
Code example
Application -> Firebase client SDK -> FCM registration token
|
v
Trusted backend -> PulseGrid device registration
|
v
PulseGrid project -> queue -> Firebase FCM -> device
Notes
One notification sent to 200 devices is 200 targeted device deliveries. The PulseGrid dashboard does not need to remain open because dispatch is server-side.
For production, run the web application, Redis, Celery worker and Celery Beat as configured by the platform.