Websockets Trigger

Hello n8n,

Congratulations on the thriving open-source project you’ve managed to build up! I’m happy to be part of this great community!

Have you considered using websockets as a Trigger?

I have this case where we would like to send triggers to n8n without having to manually define the URL of each webhook (each having a different URL makes them usable in one place), but rather set up more general Triggers to listen for certain events being sent to them. This way, we would be able to trigger only one endpoint from the server, which would then propagate to all the n8n workflows subscribed and configured accordingly.

As options, I believe that the host (ws url), the channel to subscribe to and the event to bind would do.

Thanks,
Robert

Welcome to the community, @roberteles! I hope you find your time here beneficial.

Your question actually got me thinking about whether or not this could be accomplished using NGINX as a proxy in front of n8n and then modify the request to connect with the correct webhook in n8n. That way, it reduces the pressure on n8n (it is, after all, just a single threaded process) and it does not require n8n to change how it works.

Just a thought…

1 Like

Hi Tephlon – happy to be here!

I considered that as well – creating a “webhooks mapping” layer between the triggering services and n8n, so that I could abstract out the urls. The challenge there becomes maintaining the webhooks and their maps – any change on n8n’s side would need to be registered/deregistered/changed with the mapping service. My non-technical colleagues would have a hard time maintaining this.

Thanks a lot @Tephlon! We are also currently working on making n8n more stateless which would help a lot in what you describe.

@roberteles welcome to the community! Did you actually see the Execute Workflow-Node. A Webhook-Node in combination with that one should actually allow you, to do what you have planned, very easily.

1 Like

Now wouldn’t it be cool if we could configure n8n to manage the NGINX proxy so that it would handle the required configuration changes! :smiling_face_with_three_hearts:

That way, the non-technical people can go about their non-technical ways and we technical people can continue to feel smart! :grin:

It looks like you can use the Kong Gateway to provide an NGINX API that you could then create a custom n8n node to manage the NGINX proxy.

Sounds like a fun weekend project!

@jan
One of the challenges with n8n is that it is so flexible and can do so many things (especially once you learn how to create your own nodes) is that it is tempting to say, “I’m sure we can figure out how to get n8n to do that!” to pretty much everything.

I think it is important that we allow tools and systems to do what they do best and let other tools fill for other things. In my mind, n8n is great at:

  1. Easily passing information between disparate systems
  2. Automating tasked based on various triggers

In my opinion (and it is only my opinion), maintaining focus and scope on those two goals is paramount to the success of n8n. It is one of those situations where if n8n tries to do everything, it will end up doing nothing.

This is why I am trying to open up people to the possibilities that there are other ways to accomplish what they are looking to do without having to recode n8n. If we can assist with solutions that use n8n as a part of the solution while incorporating other technologies, I believe it will help to expand n8n’s adoption/acceptance while expanding the use cases for n8n.