Developing an app extensible with standalone executable plugins

Question

I am developing a desktop application (C++/Qt), which might be roughly represented as consisting of two parts - data-handling part and the GUI.

I want the data-handling part to be extensible with 3rd-party plugins. After thinking over possible strategies (and googling :) ), I've come to the conclusion that probably the optimal way is to use plugins as standalone executables which might be started as separate processes from my main app.

The advantage here is that 3rd-party plugin developers are not restricted to using the same language that I use for the main app (C++) - they might create plugins with whichever language they choose. The only thing they need to know is the protocol of data exchange with the main app (for which I see two alternatives - either using standard pipes to read/write data from/to plugins as child processes, or I might set up local server and then exchange data with plugins via, e.g., HTTP requests).

But then I thought - given this advantage, why can't I remember a single desktop application which uses such strategy? :) Are there drawbacks that I miss? Does anyone know of a desktop app which works with plugins written in entirely different languages?

Answer 1

I can recommend this approach. Of course, there are a couple of potential drawbacks - depending on what you're doing:

• Performance You'll have to go through serialization, deserialization and IPC. However, you'd have to work with a really high volume of data or a seriously performance-critical application for this to actually matter.

• Convenience The plug-in developer will have to implement your protocol. While this provides flexibility, it also requires additional work. You could mitigate this somewhat by making your protocol simple, using standard technologies and/or providing a library in a few popular languages.

• Integration A few applications may want their plug-ins to have very extensive control over the host application's model. Having to go through the abstraction of your protocol might be quite tedious compared to simply getting a pointer to the actual model.

For most applications, I'd say the benefits substantially outweigh the drawbacks.

There is at least one example of such a design that I can think of: the Language Server Protocol. It allows code editors to communicate with editor-independent, language-specific plug-ins that provide features such as syntax-highlighting, auto-complete, etc.

The protocol is supported by various editors (e.g. VS Code, emacs, vim) and many language servers have been written in a variety of different languages.