Request for feedback: Node Generator

Hello everyone,

I am a part of a summer fellowship that is contributing to n8n. After creating a few regular nodes, we decided to work on a tool to make it easier to make the nodes you need. We are looking for community suggestions and feedback!

Basically, our application is going to automate the creation of regular nodes (as they are generally just HTTP clients). Specifically, when you input the basics of your node (which resources, operations, and other input fields are needed), the nodemaker will return back the code for this node. This product will simplify node creation and helps PRs get merged faster because the nodemaker takes care of codebase conventions for you.

As long as the nodemaker directory is placed next to the n8n and n8n-docs folders, the nodemaker can generate and place the proper files to add in a new node to n8n.

These operations are currently supported:

Script Action
nodegen Generate *.node.ts, GenericFunctions.ts, *Description.ts (optional), and *.credentials.ts.
packgen Generate a package.json updated with node path and credential path insertions.
docsgen Generate a node functionality doc file and a node credential doc file in markdown.
icongen Generate five images as icon candidates.
resize Resize one of the generated icon candidates to a 60×60 px PNG file.
place Move files at /output to the n8n and n8n-docs repos.

A more detailed description of the nodemaker is here.

We would also love feedback on the UI mockups here.

Some of the main questions we are considering are:
Would you use this as a CLI tool, a desktop app, or a web app?

  • The CLI tool will be an easy extension to a desktop or web app.
  • We are leaning towards creating a desktop app because a web app will not have the file placement functionality.

What other functionality would you like to see in the nodemaker?

Feel free to message me with any questions, comments, or concerns about this project.


Hey @erin2722,

The node maker is one of the ideas that I had a while back which I was going to tackle when I had time. Thanks for jumping in on this!

To answer your questions:

For me personally, I would use it regardless of the UI. But, a few thoughts on the tool:

  1. The sense that I get is that this will be a tool used by people who deploy n8n. This may or may not be the end user and is likely someone who is more technical. Because of this (and like me), the UI may not matter much to the end user.
  2. Pros and Cons of each tool (from my perspective):
    • CLI
      • Pro
        • Easier for scripting and automating
        • UI very easy to develop
        • Common way of using tools for pretty much all applications
        • Smaller footprint and generally fewer dependencies
      • Con
        • Point and click users may be lost
        • Not as intuitive as a GUI interface
        • Might be a barrier to entry for those who never user CLI tools
    • Dekstop
      • Pro
        • Everyone is familiar with this type of an application
        • Usually very intuitive as long as standards are followed
      • Con
        • May run into challenges making it work cross-platform (though I do know there are ways to do this)
        • Often more difficult to troubleshoot, especially when the desktop environment is not managed and they could have anything running that might cause problems with the app
    • Web
      • Pro
        • Everyone knows how to use a web browser
        • The platform where services run (i.e. the web server) are consistent for all users, making troubleshooting a lot easier
      • Con
        • May run into issues with how different support different aspects of HTML/javascript
        • Some security conscious users will not allow scripts to run in their browser which makes it difficult to ask them to reduce their security levels to use your app

So, here is the big one for me. I would love to be able to point this tool at an API that follows the Swagger OpenAPI Specification, RAML or API Blueprint and have it crawl the API/documentation to automatically create the node and all of its functions.

Because each of these standards is well documented, there should be enough logic behind them to allow this tools to know how the API will behave and test that behavior before adding it into the node(s).