Exemple d'implémentation

Pour migrer de l'ancienne API Web Fitbit vers l'API Google Health, vous passerez des bibliothèques OAuth2 générales à la bibliothèque Google Auth. Vous trouverez ci-dessous une suggestion d'architecture et une implémentation en pseudo-code écrit en JavaScript pour gérer cet état de "double bibliothèque".

1. Le "Middleware Switch"

Étant donné que vous ne pouvez pas migrer tous les utilisateurs en même temps, votre backend doit déterminer quelle bibliothèque utiliser en fonction du apiVersion actuel de l'utilisateur stocké dans votre base de données.

Mise en œuvre

const { OAuth2Client } = require('google-auth-library');
const FitbitV1Strategy = require('fitbit-oauth2-library').Strategy;

// 1. Initialize the Google Health API Client
const GHAClient = new OAuth2Client(
  process.env.GOOGLE_CLIENT_ID,
  process.env.GOOGLE_CLIENT_SECRET,
  process.env.REDIRECT_URI
);

// 2. Create a Unified Fetcher
async function fetchSteps(user) {
  if (user.apiVersion === 4) {
    // ---- GOOGLE OAUTH LIBRARY LOGIC ----
    GHAClient.setCredentials({ refresh_token: user.refreshToken });
    const url = 'GET https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints';
    const res = await GHAClient.request({ url });
    return res.data;
  } else {
    // ---- FITBIT WEB API LEGACY LOGIC ----
    // Use your existing Fitbit open-source library logic here
    return callLegacyV1Api(user.accessToken);
  }
}

2. Migrer le flux UX

Pour maximiser la rétention, utilisez un modèle "Interrupt-and-Upgrade". Cela garantit que l'utilisateur n'est pas obligé de se reconnecter tant qu'il n'est pas déjà engagé avec l'application.

Logique de redirection

Lorsqu'un utilisateur de l'API Fitbit Web accède à une fonctionnalité spécifique, déclenchez la migration :

app.get('/dashboard', async (req, res) => {
  const user = await db.users.find(req.user.id);

  if (user.apiVersion === 1) {
    // Render a "soft" migration page explaining the Google transition
    return res.render('migrate-to-google', {
      title: "Keep your data syncing",
      message: "Fitbit is moving to Google accounts. Re-connect now to stay updated."
    });
  }

  const data = await fetchSteps(user);
  res.render('dashboard', { data });
});

3. Principales transitions techniques

Lorsque vous rédigez vos scripts de migration JavaScript, gardez ces différences à l'esprit :

Fonctionnalité	API Web Fitbit (ancienne)	API Google Health (Google-Identity)
Point de terminaison du jeton	https://api.fitbit.com/oauth2/token	https://oauth2.googleapis.com/token
Bibliothèque Auth	Open Source standard	Authentification Google
Champ d'application	activité	https://www.googleapis.com/auth/googlehealth.activity_and_fitness
ID utilisateur	ID Fitbit encodé renvoyé dans la réponse /oauth2/token	ID utilisateur renvoyé par le point de terminaison users.getIdentity

4. Checklist de rétention

• Persistance de la session : ne supprimez pas l'ancienne session de l'API Web Fitbit de l'utilisateur tant que le jeton access_token de l'API Google Health n'a pas été validé et enregistré dans votre base de données.
• Révocation automatique : une fois la migration de l'API Google Santé terminée, utilisez une requête POST vers l'ancien point de terminaison de révocation Fitbit : https://api.fitbit.com/oauth2/revoke. L'utilisateur ne verra ainsi pas d'autorisations de l'application "en double" dans ses paramètres Fitbit.
• Gestion des erreurs : si un appel Fitbit renvoie une erreur 401 Unauthorized, redirigez automatiquement l'utilisateur vers le flux Google OAuth au lieu d'afficher un message d'erreur.