I just have a quick question on providing Community Nodes. I have a fledging app just getting some uptake now, and some of my users have requested/suggested N8N integration. The thing is my platform is a collection of tools, and they do different things so they don’t necessarily have identical inputs/outputs/configs. From one perspective it would make sense to have a node for each function, but I don’t want to flood out a slop-bucket full of them and create clutter. Is there some reasonable number of node types that a platform might offer that’s “useful without being annoying”?
Hey @Chad_R, while you wait for a response, here are some things that might help:
Suggested resources
Automatically matched to your question.
Docs:
Forum:
@Gallo_AIA - you’ve helped with similar issues before, can you take a look?
Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.
Hi @Chad_R Welcome!
One package with one node for the platform, each tool as a Resource and its actions as Operations under it, and displayOptions hiding the fields that do not apply to the current selection. Verification expects exactly one third-party service per package, with a trigger node alongside if your platform emits events, so splitting per function counts against you there.
Every operation still gets its own entry in the nodes panel through the action property, so someone searching lands on “Create report in YourApp” without needing to know your node exists.
There is no magic number, to this but a good idea is to build a node per distinct resource/entity your API exposes, not per feature. If three of your “tools” operate on the same core object with different actions, this is one node with an operation dropdown and not three nodes. Different resources with different auths or shapes, however, should be separate nodes.
Now most well-scoped community nodes will land in the range of 1-4 nodes for platforms that have a dozen+ endpoints. If you’re looking at more like 8+ you can probably collapse them into resource+operation pairs instead of standalone nodes. You should also add a trigger node separately if any of your tools support webhook/polling rather than folding into an action node.
I think that you need to consider some steps: Functionality Grouping: Instead of creating a separate node for each function, consider grouping related functionalities into a single node with configurable options. This can reduce clutter while still providing users with the flexibility they need. User Feedback: Engage with your users to understand which functionalities they find most valuable. Prioritize creating nodes for the most requested features first, and then expand based on demand. Simplicity: Aim for a clean and intuitive user experience. Too many nodes can overwhelm users, especially if they have similar purposes. Focus on clarity in naming and documentation.