Nango vs Pipedream: Authorisation in the Age of AI

Authorisation des applications tierces est un défi persistent pour les développeurs. Chaque fournisseur de services a ses propres particularités, et gérer les flux OAuth ou les clés API sur behalf des utilisateurs ajoute complexité à tout système. Les outils comme Nango et Pipedream Connect s’efforcent d’enrayer ce processus en abstrayant l’autorisation pour que vous puissiez vous concentrer sur la mise en œuvre de fonctionnalités. Les deux services vous permettent d’autoriser des applications tierces sur behalf des utilisateurs, mais ils approchent le problème de manière similaire.

Nango est un joueur plus récent et centré sur les développeurs. Il est conçu pour ceux qui souhaitent avoir le contrôle et la flexibilité, avec une focus sur l’intégration d’API dans votre application. Pipedream Connect, quant à lui, a des racines dans l’automatisation de workflow. C’est principalement un outil UI-driven, mais il offre également des options pour les développeurs via des composants basés sur du code. Dernièrement, Pipedream Connect a introduit la fonctionnalité Pipedream Connect qui se rapproche plus de modèle d’autorisation de Nango.

Comment ils gèrent l’autorisation

Les deux services vous permettent d’autoriser des applications tierces pour vos utilisateurs. Vous commencez en configurant un fournisseur (ou “app” dans le jargon Pipedream) avec un secret partagé. Le service gère la danse OAuth, générant un jeton lié à votre utilisateur. Une fois autorisé, vous obtenez une réponse de webhook avec le jeton, que vous pouvez stocker aux côtés de votre user_id dans votre base de données.

Ensuite, les deux services vous permettent d’utiliser le jeton pour agir en tant que représentant de l’utilisateur. Vous pouvez déclencher des actions directement ou effectuer des requêtes proxy, où le service remplace votre token par le jeton OAuth du fournisseur derrière les scenes. Le flux est similaire, mais l’exécution diverge.

Avec Nango, lorsque le jeton est créé, les utilisateurs peuvent être automatiquement souscrits aux points de synchronisation. Nango commence à stocker des enregistrements - comme nouveaux courriels ou mises à jour CRM - et envoie des événements vers un webhook unique (ou deux). Vous pouvez ensuite récupérer les données comme vous le souhaitez. Pipedream prend une approche plus manuelle. Vous créez des déclencheurs personnalisés pour chaque utilisateur et composant d’application, chacun lié à une URL de webhook unique. Puisque la charge utile du webhook ne définit pas naturellement l’utilisateur, cet URL devient votre moyen de map les événements vers la bonne personne.

Définition des termes

Les deux services emploient des étiquettes différentes pour des concepts similaires:

• Pipedream: App vs Nango: Provider – Le service tiers que vous voulez connecter, comme Gmail ou Slack.
• Pipedream: Source/Event Source/Trigger/App Trigger Event vs Nango: Sync – Un événement spécifique, comme “nouveaux courriels” ou “nouvelle mise à jour ajoutée”.
• Pipedream: Components vs Nango: Endpoints – Les composants de Pipedream incluent des déclencheurs (événements) et des actions (tâches), tandis que Nango les sépare en synchronisations (pulls de données) et actions (tâches comme envoyer un courriel).

Par exemple, “nouveaux courriels” pourrait être un déclencheur dans Pipedream ou une synchronisation dans Nango, tandis que “envoyer un courriel” est une action dans les deux.

Clients OAuth : Une différence clé

Pipedream Connect a une fonctionnalité étonnante : vous pouvez utiliser son client d’application OAuth au lieu de créer votre propre. Prenez Google par exemple - créer votre propre application OAuth exige la soumission d’un vidéo et l’attente d’une approbation manuelle. Pipedream évite ce problème en fournissant un client pré-approvable. Le revers est moins contrôle sur l’expérience d’autorisation, mais le branding neutre de Pipedream le rend inoffensif.

Nango ne propose pas cette option. Vous devez créer votre propre client OAuth avec chaque fournisseur. C’est plus de travail à l’avance, mais vous conservez tout contrôle sur l’expérience d’autorisation.

Exemples de code

Voici comment vous pouvez travailler avec chaque service, gardant cela concise où possible.

Nango

• Autoriser une connexion:

  import Nango from '@nangohq/frontend';
  const nango = new Nango();
  nango.openConnectUI({
    onEvent: (event) => {
      if (event.type === 'connect') console.log('Auth successful');
    }
  });
  const res = await fetch('/sessionToken', { method: 'POST' });
  nango.setSessionToken(res.sessionToken);

• Payload d’événement Webhook (Événement Sync):

  {
    "connectionId": "user123",
    "providerConfigKey": "google",
    "syncName": "gmail-emails",
    "model": "Email",
    "responseResults": { "added": 5, "updated": 0, "deleted": 1 },
    "syncType": "INCREMENTAL",
    "modifiedAfter": "2025-03-26T10:00:00Z"
  }

• Lister des enregistrements:

  import { Nango } from '@nangohq/node';
  const nango = new Nango({ secretKey: 'your-secret-key' });
  const records = await nango.listRecords({
    providerConfigKey: 'google',
    connectionId: 'user123',
    model: 'Email',
    modifiedAfter: '2025-03-26T10:00:00Z'
  });

• Appeler une action:

  import { Nango } from '@nangohq/node';
  const nango = new Nango({ secretKey: 'your-secret-key' });
  const result = await nango.triggerAction('google', 'user123', 'send-email', {
    to: 'friend@example.com',
    subject: 'Hi'
  });

• Requête proxy:

  const options = {
    method: 'GET',
    headers: {
      'Connection-Id': 'user123',
      'Provider-Config-Key': 'google'
    }
  };
  const response = await fetch('https://api.nango.dev/proxy/gmail/v1/users/me/messages', options);

Pipedream Connect

• Autoriser une connexion:

  import { createFrontendClient } from '@pipedream/sdk/browser';
  const pd = createFrontendClient();
  async function connectAccount(token) {
    pd.connectAccount({
      app: 'google',
      token, // From your server
      onSuccess: ({ id }) => console.log(`Connected: ${id}`)
    });
  }
  const { token } = await fetch('/connectToken', { method: 'POST', body: JSON.stringify({ external_user_id: 'user123' }) });
  connectAccount(token);

• Déployer un déclencheur:

  import { createBackendClient } from '@pipedream/sdk/server';
  const pd = createBackendClient({ credentials: { clientId: 'id', clientSecret: 'secret' }, projectId: 'proj123' });
  const { data } = await pd.deployTrigger({
    triggerId: { key: 'google-new-email' },
    configuredProps: { google: { authProvisionId: 'apn_123' } },
    externalUserId: 'user123',
    webhookUrl: 'https://yourapp.com/webhook/user123'
  });

• Payload d’événement Webhook:

  {
    "steps": {
      "trigger": {
        "event": { "emailId": "abc123", "from": "someone@example.com" },
        "context": {
          "id": "evt_123",
          "ts": "2025-03-26T10:00:00Z",
          "deployment_id": "dep_456"
        }
      }
    }
  }

• Appeler une action:

  import { createBackendClient } from '@pipedream/sdk/server';
  const pd = createBackendClient({ credentials: { clientId: 'id', clientSecret: 'secret' }, projectId: 'proj123' });
  const { exports } = await pd.runAction({
    actionId: { key: 'google-send-email' },
    configuredProps: { google: { authProvisionId: 'apn_123' } },
    externalUserId: 'user123',
    data: { to: 'friend@example.com', subject: 'Hi' }
  });

• Requête proxy:

  import { createBackendClient } from '@pipedream/sdk/server';
  const pd = createBackendClient({ credentials: { clientId: 'id', clientSecret: 'secret' }, projectId: 'proj123' });
  const resp = await pd.makeProxyRequest(
    { searchParams: { external_user_id: 'user123' } },
    { url: 'https://gmail.googleapis.com/gmail/v1/users/me/messages', method: 'GET' }
  );

MCP et introspection

Le modèle de contexte des protocoles (MCP) est comme un annuaire pour les grands modèles linguistiques (LLMs). Il standardise comment les agents intelligents découvrent ce qu’ils peuvent faire et comment agir sur behalf d’un utilisateur. Les deux Nango et Pipedream sont en train de s’intéresser à cela au fur et mesure que l’intégration des AI grandit.

Pipedream a récemment lancé mcp.pipedream.com, permettant aux développeurs de plugg MCP API calls dans leurs IDEs. Ils planifient également supporter les appels serveur MCP pour les clients bientôt (selon leur communauté de support Slack). Les déclencheurs dans Pipedream sont configurables - pensez à des déclencheurs avec des payloads personnalisées, mais cette flexibilité peut limiter l’introspection en temps réel. Le serveur MCP de Pipedream résout ce problème en définissant précédemment comment les composants déclenchent les actions.

Nango offre une API d’introspection (docs.nango.dev/reference/api/scripts/config) qui joue un rôle similaire. Elle décrit les points de synchronisation et les syncs disponibles, qui peuvent être adaptés pour l’utilisation avec des agents intelligents. La customisation dans Nango se fait via des points de synchronisation personnalisés, et ces définitions coulent dans l’API d’introspection, offrant une vue claire sur l’état du système.

Pipedream est en avance sur l’adoption de MCP, avec une vision plus polie pour les workflows AI. Nango offre une introspection plus serrée, avec des typages précises et un état en temps réel, même si elle est moins standardisée.

Résumé

Nango et Pipedream Connect abordent l’autorisation de manière distincte. Nango convient aux développeurs qui souhaitent avoir le contrôle et la flexibilité, avec des synchronisations et des actions précises. Pipedream Connect opte pour une approche plus manuelle, avec des déclencheurs personnalisés et un workflow plus flexible. Choisissez en fonction de vos priorités - contrôle ou commodité.