Does n8n currently offer any sort of global object store besides using global? I’m creating nodes for Discord and I have a very good looking proof of concept; I just would like the ability to store the discord.js client object to be shared among nodes which share the same credentials. For instance, I need to trigger upon new messages and emoji reactions, which works. However, each trigger node makes its own separate client. With a few different workflows I’ve been messing with, this would create around 10 clients connected to Discord at the same time, which isn’t ideal.
If there were a way to store a client object into an instance of a credential, this would be a bit easier and feel safer than using plain old global. When a node uses a credential, it could call a “create client” method to create a shared client object used among all nodes which use that credential. It would then make that client object available to the node methods like trigger, execute, etc. It could also call a destroy method whenever there are no more nodes using the credential.
I’m looking forward to publishing my new Discord nodes, as they’ve been quite useful to me, even during the development stages.
hm sorry. Sadly there is nothing like that and currently can also not see a simple way how to make that work as each n8n workflow runs in a separate process.
That’s understandable; I was under the impression that everything was running on the single node.js event loop. In this case, I wouldn’t even be able to use global. On the bright side, this makes nodemation seem well equipped to be made horizontally scalable.
What do you think about the concept of “workers”? As it is, I could use nodes that exchange data on a message bus such as an AMQP server. I would then have a worker running separately, having its own state and runtime, receiving commands and returning data to the message bus. This would then push the amount of clients to that bus instead of directly to Discord. I think that this could be facilitated in the UI as “workers” and *.worker.ts files. Nodes such as mine could then choose an existing worker to use or start a new one. One problem is deciding what sort of message bus that n8n would use for this. At the basic level, it could make HTTP requests to itself.
I also just realized that an easy way to fix my particular issue, since it would work to share state with a single Discord client per workflow, would be to make an object store for the workflow (instead of n8n itself) and allow nodes of the same type to share the client/session object within the same workflow. This would appear to work if each entire workflow is in its own process.