J’ai juste une petite question sur la fourniture de nœuds communautaires. J’ai une application naissante qui commence à avoir du succès, et certains de mes utilisateurs ont demandé/suggéré une intégration N8N. Le problème, c’est que ma plateforme est une collection d’outils, et ils font des choses différentes, donc ils n’ont pas nécessairement des entrées/sorties/configurations identiques. D’un certain point de vue, il serait logique d’avoir un nœud pour chaque fonction, mais je ne veux pas inonder avec un tas de nœuds qui créeraient du désordre. Y a-t-il un nombre raisonnable de types de nœuds qu’une plateforme pourrait proposer qui soit « utile sans être agaçant » ?
Hé @Chad_R, en attendant une réponse, voici quelques ressources qui pourraient vous aider :
Ressources suggérées
Automatiquement associées à votre question.
Documentation :
Forum :
@Gallo_AIA - vous avez déjà aidé avec des problèmes similaires, pouvez-vous jeter un œil ?
Suggéré automatiquement par le bot communautaire de n8n. C’est un projet pilote - veuillez partager vos commentaires ici.
Salut @Chad_R Bienvenue !
Un package avec un seul nœud pour la plateforme, chaque outil en tant que Resource et ses actions en tant qu’Operations en dessous, et displayOptions masquant les champs qui ne s’appliquent pas à la sélection actuelle. La vérification s’attend à exactement un service tiers par package, avec un nœud déclencheur à côté si votre plateforme émet des événements, donc la division par fonction compte contre vous ici.
Chaque opération obtient toujours sa propre entrée dans le panneau des nœuds via la propriété action, donc quelqu’un qui effectue une recherche arrive sur « Create report in YourApp » sans avoir besoin de savoir que votre nœud existe.
Il n’y a pas de nombre magique pour cela, mais une bonne idée est de construire un nœud par ressource/entité distincte que votre API expose, et non par fonctionnalité. Si trois de vos « outils » opèrent sur le même objet fondamental avec des actions différentes, c’est un seul nœud avec un menu déroulant d’opérations et non trois nœuds. Les ressources différentes avec des authentifications ou des structures différentes, cependant, doivent être des nœuds séparés.
Or, la plupart des nœuds communautaires bien délimités se situent dans la plage de 1 à 4 nœuds pour les plateformes qui ont une douzaine de points de terminaison ou plus. Si vous en envisagez plutôt 8 ou plus, vous pouvez probablement les regrouper en paires ressource+opération au lieu de nœuds autonomes. Vous devriez également ajouter un nœud de déclencheur séparément si l’un de vos outils supporte webhook/polling plutôt que de le fusionner dans un nœud d’action.
Je pense que vous devez considérer certaines étapes : Groupage des fonctionnalités : Au lieu de créer un nœud séparé pour chaque fonction, envisagez de regrouper les fonctionnalités connexes dans un seul nœud avec des options configurables. Cela peut réduire l’encombrement tout en offrant aux utilisateurs la flexibilité dont ils ont besoin. Retours des utilisateurs : Engagez-vous auprès de vos utilisateurs pour comprendre quelles fonctionnalités ils trouvent les plus utiles. Priorisez la création de nœuds pour les fonctionnalités les plus demandées d’abord, puis développez en fonction de la demande. Simplicité : Visez une expérience utilisateur propre et intuitive. Trop de nœuds peuvent surcharger les utilisateurs, surtout s’ils ont des objectifs similaires. Concentrez-vous sur la clarté de la dénomination et de la documentation.