Good day,
I've become fairly involved with Node Red and have a few flows that exceed the width of the canvas, can this be increased via a setting? (fingers crossed it can!).
Many thanks for this amazing tool.
Ouch, time to rethink my deployment...
If you're running a fairly recent version you should be able to hide your labels on nodes to shrink them down real nice. You may also have some success with subflows, especially if you have recurring functional structures.
1 Like
Also using links to transfer/access data onto different tabs.
Any chance this might be customisable in the future ?
Also, I noticed that you can't move nodes outside those limits using the mouse but you can using the keyboard !
I don't know. Depends if someone wants to take it on. Otherwise it'll sit in the backlog with everything else.
Wish I had the skills, I'd love to implement this feature. Out of curiosity, where is this hardcoded?
BTW, I really appreciate this awesome tool, it's literally redesigned how I interact with technology!
https://github.com/node-red/node-red/blob/master/packages/node_modules/%40node-red/editor-client/src/js/ui/view.js#L19 and 20
then you have to rebuild the project.
1 Like
I really appreciate this awesome tool, it's literally redesigned how I interact with technology
Well it was designed with tabs 
and links to connect them...
and subflows to encapsulate functionality into a single node...
1 Like
It was meant as a compliment 
I would just echo what others here have said about subflows and links - you're almost certainly better off breaking down your flow into smaller logical chunks. Sounds like you have built yourself a monolith!
2 Likes
That really depends on your use case. I am all in for creating and reusing components with subflows, but in some projects, it is really that much. We had to split one logical topic into multiple tabs, because there wasn't enough canvas space (at least vertically).
And that leads to the next issue, when you get too many tabs... 
When you are getting to this point, I would have to be questioning whether you are using the right tool for the job?
I would certainly be looking closely at resource utilisation and I would also be looking for areas of my flow that could be simplified, refactored or rewritten in code as a single function or even a custom node. Are there parts of the flows that could be more effectively written as a separate service or module?
I would also be asking devs some very careful questions about maintainability and documentation. How easy is it to understand those flows? What happens if your main devs leave? How long would it take for someone new to come in and understand such a large set of flows?
Node-RED is a fantastic tool but it isn't the tool for every job.
Just a few thoughts with my IT manager hat on.
2 Likes
Okay, let me explain our use case a little deeper.
Background:
We are a manufacturer of custom engineering lines, so each project has different requirements. These can be a quite large lines of connected physical processes.
In our terminology, a line consists of different modules, each module has one or more stations. At each station there can be one or more physical processes. Each part (the product) is handled through the line and is usually identified by a unique ID.
Physical processes can be screwing, joining, pressing, measuring, welding, laser processes, ...
you name it.
Use case for Node-RED:
We are using Node-RED as a data processor between the field (Siemens PLC, low level) and higher level systems (databases, the customer's MES, etc...).
It is achieved by some custom nodes for the PLC communication and decoding/encoding of raw data structures.
We already try to keep the flows as simple as possible, so complex functions are put into stand-alone services that are just invoked by Node-RED.
Node-RED is merely the "man" in the middle. 
Per station we have to handle different kinds of requests from the PLCs, like the following:
part check-in
- can the part be processed in this station?
- retrieve production parameters (limits for measurements, program parameters
for external devices, ...)
part check-out
- process part-related data (hand over to customer systems, internal
databases, ...)
A common flow looks like this, simplified.
plc in -> decode struct (raw bytes) -> process -> call a service api -> generate response -> encode -> plc out
This is usually a one- or two-"liner" including a catch node for error handling in each flow.
Each flow involves more or less unique data structures, depending on the physical process. These are decoded into an object using a structure definition (Siemens SCL).
Generic stuff is put into subflows and now that these are customizable with parameters (v0.20), they have become really useful!
Regarding the canvas space limitation and tab navigation:
For now the common practice is to put these flows for checkin and checkout requests for each module into a tab. So you would get "M1 - checkin", "M1 - checkout", ... for module 1. Now imagine a production line with 10-15 modules and at least 10-20 different requests per module that need to be handled.
So the number of flows required scales with the complexity of the line (number of modules/stations/processes).
To address your concerns:
The runtime can handle this amount of processing perfectly. 
That is exactly
what NodeJS (and Node-RED) was made for. It is merely a matter of the
presentation in the flow editor and how you can navigate your flows.
From the perspective of software development in the context of custom mechanical engineering, doing all this with Node-RED gives us exactly the flexibility we need. There is often a requirement for "special" handling due to customer wishes. Furthermore, each customer has different backend systems.
Compared to our previous solution, we can apply changes a lot more quickly, now even at runtime. The initial setup of new projects is easier.
And you can actually see what is happening with your data and why, making it easier for colleagues to become acquainted with the project's specifics.
From that experience the last 1-2 years, I believe moving to Node-RED for that
kind of stuff was a perfect choice. 
Quite a lot of text.... I hope I wrote it in an understandable manner. 
11 Likes
