Finances
%201.png)
Daniel
Expert en No-code, Latenode Ambassadeur
16 novembre 2023
%20(1)%20(1).png)
.svg){kind=icon}
Salut, amateurs de low-code ! C'est Daniel de Latenode!
Trois minutes de lecture de ce matériel permettront de découvrir toute la vérité sur les systèmes de monétisation qu'utilisent tes plateformes low-code préférées, afin que tu prennes conscience de la raison pour laquelle Latenode est 89,7 fois moins cher que Zapier lorsqu'il s'agit d'automatisations avec des milliers d'opérations.
Toutes les images de cet article sont destinées à des fins d'illustration uniquement. Le symbole '-💲' représenté dans les images indique une action de débit de fonds interne à la plateforme et ne doit pas être interprété comme le coût d'une opération individuelle ou le coût global du scénario.
.png)
Commençons par Zapier, où le système est simple.
L'exécution de chaque action de ton flux de travail consomme une tâche - des crédits que tu utilises sur la plateforme pour la facturation.
Plus il y a de tâches dans ton flux de travail, plus tu paies. Et peu importe la quantité de données que tu traites ou le nombre de ressources serveur que tu as utilisées. Une action exécutée ? Tu es facturé !
Cependant, l'équipe de Zapier est fière de ne pas facturer l'exécution du déclencheur - le nœud de départ qui exécute ton flux de travail. C'est appréciable ! Malgré tout, tu ne peux pas ajouter plus d'un déclencheur dans ton flux de travail. Donc en fait, tu es protégé contre les dépenses liées à une seule tâche supplémentaire par automatisation. Ce n'est pas très grave.
De plus, Zapier te permet de mettre en boucle la partie choisie de ton flux de travail lorsque la séquence d'actions peut être exécutée à plusieurs reprises.
Et oui, tu dois toujours payer avec une tâche pour chaque action exécutée dans ta boucle.
Pipedream fonctionne différemment - il utilise des crédits au lieu de tâches, et Pipedream facture un crédit par 30 secondes de temps de calcul à 256 mégaoctets de mémoire par exécution de flux de travail.
Un tel système semble plus équitable, car ce n'est pas la même chose de recevoir une requête d'une seule ligne du serveur et de traiter des données complexes. Ce dernier nécessite beaucoup plus de ressources et de temps, et par conséquent, le fait d'être facturé sur la base du temps de calcul réel et de l'utilisation de la mémoire garantit que les utilisateurs ne paient que pour les ressources qu'ils consomment.
Mais il y a une chose... Pipedream ne fournit pas aux utilisateurs une boucle comme le fait Zapier, c'est pourquoi il n'est souvent pas possible de terminer ton processus au sein d'un seul flux de travail que tu construis sur Pipedream. La seule solution de contournement suggérée consiste à utiliser deux flux de travail différents.
Pourquoi en est-il ainsi ? Parce que si Pipedream te facture chaque 30 secondes de temps de calcul, il te facture aussi chaque exécution de ton flux de travail. Et apparemment, ce n'est pas très rentable de te permettre de boucler des actions et de tout exécuter dans le cadre d'un seul scénario.
La première conspiration low-code révélée.
Lorsqu'il s'agit de faire, tout redevient simple - la facturation est basée sur l'exécution de chaque étape.
Make est extrêmement génial pour construire des architectures complexes, où tu peux construire des automatismes visuellement et connecter tout à tout, et pas seulement chacun au suivant comme le fait Zapier. Les seules différences sont :
La seule chose qui manque à Make (et c'est intentionnel), c'est la possibilité d'intégrer du code personnalisé pour travailler avec les données. Par conséquent, tu ne peux construire des architectures complexes qu'en utilisant des outils préconstruits.
Est-ce que cela a une incidence sur le prix ? Bien sûr ! Ce que tu peux obtenir à partir d'une seule action JavaScript sur Pipedream nécessite l'enchaînement de 3-5-7-9 actions différentes sur Make.
Voici un exemple d'une partie du scénario de Make qui peut être remplacée par un seul module JavaScript sur Pipedream :
Cependant, l'utilisation de Make entraînerait la facturation de quatre opérations. Ceux d'entre vous qui travaillent avec des données comprennent à quel point la logique de transformation et d'agrégation peut être complexe. C'est pourquoi cet exemple est quelque peu simplifié afin d'illustrer clairement le propos.
La deuxième conspiration low-code révélée.
En ce qui concerne Latenode, le modèle de tarification est le même que celui de Pipedream - un crédit équivaut à 30 secondes de temps de calcul.
Et bien que le lancement de ton scénario nécessite également un crédit, il y a une énorme différence - Latenode ne te force pas à exécuter le nombre maximum de scénarios comme le fait Pipedream si tu as besoin d'itérer ou de mettre des données en boucle. Tu es donc libre d'effectuer des itérations au sein d'un même scénario.
En même temps, la plateforme ne te contraint pas non plus au nombre maximum d'actions dans ton scénario. Le nombre d'opérations ne sera pas facturé. C'est exactement la raison pour laquelle tu disposes également d'une flexibilité totale du code avec le module JavaScript, qui inclut également le travail avec les paquets NPM à l'intérieur. Le traitement de données volumineuses est très apprécié sur Latenode.
Par conséquent, Latenode représente la plateforme la plus flexible, la plus transparente et la plus juste dans le contexte des modèles de tarification. Ainsi, les utilisateurs ne pensent à rien d'autre qu'aux automatismes.
Cela signifie-t-il que tu dois abandonner les plateformes que tu utilises depuis des années ? Pas du tout. Cependant, dans les scénarios où tu dois transformer d'énormes quantités de données sur Make ou itérer sur des milliers d'objets JSON sur Pipedream, envisage de faire une requête HTTP à Latenode. Transfère les données là-bas pour une transformation plus rentable dans un environnement adapté. De cette façon, tu pourras éviter de surpayer tes automatisations.
Tendez la main à la communauté 'low-code' de LatenodeLa communauté low-code sur Discord et pose des questions sur l'automatisation sur la plateforme elle-même.
