If I give a real example, I want to create a desktop software that includes:
- electron js app that communicates with react js using IPC channels.
- I need to communicate with software that only has a Python module. so I created a TCP server/client communication for this purpose.
- I have a printer with C++ SDK. so I also created a TCP server/client between electron and C++.
For now, I package Python using PyInstaller and compile C++ using g++, and put them as static files alongside the electron app. Then from electron code, I use child processes with bash commands to run Python and C++.
then I package the electron app using electron-builder in a .exe or .deb file.
What I tried:
I tried to make TCP communication between different parts.
Question:
Is there any way that I can communicate between these parts apart from TCP that I used?
3
Multi-language development is easier if the different language components use a common runtime environment (e.g. Microsoft’s CLI or Java’s JVM/JRE). In this case, you just have to define APIs of your components and rely on the common base.
If this is not possible, you’ll need to rely on inter-process
communication mechanisms of the underlying OS (not always portable: e.g. memory mapping in posix family vs windows ), or as you did, on more classical TCP/IP communication between standalone components. This last approach has the advantage of a robust communication, enabling nice service oriented architectures even if this is not your prime purpose now. Of course, the glue to launch the different components might then look somewhat clumsy.
As Christophe mentioned, there are 2 main options:
- Spawning a child process https://www.electronjs.org/docs/latest/api/utility-process and sending commands as you would do via terminal. This is similar to nodejs forking method, but it spawn directly the process. You can also use the nodejs, but you need to have a nodejs installation path and it’s not the most forward and robust way to do it.
utilityProcess creates a child process with Node.js and Message ports
enabled. It provides the equivalent of child_process.fork API from
Node.js but instead uses Services API from Chromium to launch the
child process.
- The second option would require to either publish a library and use it but this is dependent on each operating system and I would say it’s something you don’t want to do.
The first option works better as using an api, but if you need to push data from the child process might be more difficult, but better to check it the documentation.
My advice is to stick to TCP/IP communication if it works flawlessly, because there a big rabbit hole at this inter-process communication part.