About FCM, multiple environments, slugs, and server keys

Hi everyone,
I have a doubt about the real-life workflow for an Expo App I am building for an MVP.

I started with one Firebase project, and when I wanted to implement push notifications, everything went well: I added an Android App to the Firebase project, uploaded the server key, and everything is working fine.

Now, I created two additional projects, let’s call them [project]-staging and [project]-development:

  • [project]-development is for… development :slight_smile:
  • [project]-staging for internal testing of specific features once finalized
  • [project] would be the master for the production variant
    Everything is fine, I am using APP_ENV for the variants, --project to deploy functions to the right project, and will use release channels to manage OTA updates.

Now, the topic of this entry: notifications. They are set up with 1 Android App that I have set for the [project], and everything works well (I just make sure that the Expo Tokens are deleted/updated properly in the users’ collection), and Server Key is set.

Yet, looks like I can’t avoid creating 1 Android App per project, or at least for [project]-staging/production, if I want to add crash reports or use app distribution for testing. I tried to do it, I can load the right google-services.json file based on the built environment, I use the right experienceID as well, BUT that’s not enough: as far as I can read in this Forum I can’t set up a Server Key per project (e.g. using --project=staging), so at all time only one of the Android App will have working notifications… is that right, or am I missing something, or just confused about this topic?

The question is: what are the best practices for multiple environments real-world apps?
How do I properly set up push notifications (plus crashlytics/app distribution) if I need multiple projects/apps but I can only use one Server Key at a time?

Thanks in advance,
Danilo

Not sure if this is a good practice (just what I do). I have my app or background jobs for scheduled notifications send a request to a small notify backend service I run (basically HTTP endpoint). When I send for a notification to be sent I include the title, body but also some data from what environment it came from (e.g. dev, staging, live).

My notification service takes care of sending the data to expos notifications services and handling errors. The end users app doesn’t use that extra meta data for what environment it came from but the notification service I run will log it and from that I can see in which if any env stuff is failing.

Hey Tobias,
thanks for your answer!

If I understand correctly, with your approach I would add a 4th firebase project (let’s say NotificationProject) with a cloud function that sends notifications: in order to do that, I’d need a dummy Android app (not a real App, just a Firebase app) with the only purpose of enabling push notifications from that cloud function - I would get the Secret Key from this project.

Still, my apps from the other firebase project (e.g.[project]-[enviroment]) will have their own google-services.json as it’s needed for logging/analytics/app distribution, etc.: would notifications work for these apps built with a different google-services.json? I understand you send a POST to another service to trigger notifications, but I am not sure if I need some specific value in google-services.json to allow an App to receive notifications using a specific Secret Key (the one that NotificationProject is using).

Not sure I have explained myself here but looks like each google-services.json is “linked” to a Server Key… is there any key/value in charge of it, that I can move to other google-services.json files? Is this a good thing to do, or is there a 'standard approach from Expo point of view?

I guess that if I had just one Firebase project for all my environments (maybe having documents with a prefix to identify dev/staging/prod) I wouldn’t have this problem, but it doesn’t really look like a good idea to have all documents of all enviroments in the same firestore db.

Yes I think that sounds about right, tough to figure out your setup from just text but like you said another service with the only purpose of enabling push notifications is what I have setup.

If you look at Sending Notifications with Expo's Push API - Expo Documentation and the diagram there, the bit under “Your Backend” for me is that service. However mine is not a Firebase app but some Lambda functions in AWS (you’ll have to forgive my if I mix up my tech as I’m not as familiar with GCP).

My apps will push notifications to that backend (with extra meta data about the environment/build). Then after being logged and metrics gathered I send it to the Expo backend which sends it to FCM or APNS. However I only have one key and rely on my backend to determine where notifications come from. After that the expo backend sends them all to the same place so possibly not ideal like you say.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.