Node.js实现FCM HTTP v1 API推送的Token刷新等问题咨询

Great job rolling your own FCM implementation with the HTTP v1 API—since most npm packages are still stuck on the legacy API, that's a solid move. Let's break down your questions one by one:

1. How to get a valid refresh token? #

You don't need one—this is a key point about service account JWT authentication for FCM. The jwt-placeholder value you're seeing is intentional. Service account JWTs use a self-signed authentication flow, where instead of using a refresh token to get a new access token, the OAuth2Client will automatically re-sign a new JWT behind the scenes when the current access token expires (every hour).

You don't have to handle refresh tokens manually here; the Google Auth Library takes care of token rotation automatically. Just make sure your OAuth2Client instance is reused across requests (don't create a new one every time you send a notification) so it can cache and refresh the token properly.

2. Can I call OAuth2Client methods without frontend interaction (like generateAuthUrl)? #

Absolutely—this is exactly what service account authentication is designed for. Frontend flows like generateAuthUrl are for user-centric OAuth (when you need access to a user's data), but FCM server-to-server requests use service accounts which are fully backend-only.

Here's a quick example of how to initialize the client correctly without any frontend steps:

const { OAuth2Client } = require('google-auth-library');
const keys = require('./service-account-key.json'); // Your service account JSON file

const oAuth2Client = new OAuth2Client({
  clientEmail: keys.client_email,
  privateKey: keys.private_key,
  scopes: ['https://www.googleapis.com/auth/firebase.messaging']
});

// You can either call authorize() upfront, or let request() handle it automatically
async function sendNotification(payload) {
  const res = await oAuth2Client.request({
    url: 'https://fcm.googleapis.com/v1/projects/YOUR_PROJECT_ID/messages:send',
    method: 'POST',
    body: payload
  });
  return res.data;
}

The client will handle fetching the initial access token and refreshing it when needed, no user interaction required.

3. Does using the request method block code? #

Only if you're using the callback-based version and writing synchronous code around it—but even then, Node.js's I/O is non-blocking. The best practice is to use async/await with the promise-based version of request() (which the Google Auth Library supports), so your code remains non-blocking and easy to read.

The example above uses async/await, which lets your Node.js process handle other requests while waiting for the FCM API response. No blocking here.

4. Do I need to introduce a message queue? #

It depends on your use case:

• Small-scale, low-volume pushes: No need. If you're sending a few dozen notifications per minute, direct async requests will work fine.
• High-volume pushes or reliability requirements: Yes. If you're sending hundreds/thousands of notifications, or need to guarantee that no notifications are lost if your server restarts or the FCM API is temporarily unavailable, a message queue (like BullMQ, Bee-Queue, or even Redis-based queues) is a good idea.

Queues let you decouple your notification trigger from the actual sending process—you enqueue the notification job, and a worker process handles sending it asynchronously. They also support retries for failed requests, which is crucial for reliability with FCM (since transient errors can happen).

内容的提问来源于stack exchange，提问作者Will Kru