Hybrid applications seem to be gaining traction now. In what follows, I’d like to present thoughts on an alternative to the emerging standard hybrid app architecture.
The conventional hybrid architecture
In this model, which to the best of my knowledge is used by Electron, NW.js, and others, the user interface is rendered as HTML using whatever HTML, CSS, and front-end JS frameworks you desire. The use of Web technologies for the UI is an explicit goal of this architecture.
The UI is tightly bound in a one-to-one relationship with the app engine.[^1] The app engine is implemented with a Web back-end technology, typically Node.js. The app engine makes system calls through the engine’s baked-in features or through generic child_process.exec()-like calls. This means custom and platform-specific behaviors that the app may require will need to be implemented as external child_process.exec() callable units.
This architecture does a good job of leveraging Web technologies to create secure conventional desktop apps. In addition, frameworks like Electron and NW.js have matured to the point that developing hybrid apps that use many desktop app conventions is relatively easy.
An alternative hybrid architecture
In what follows, I present what I believe is a more flexible approach to developing hybrid apps—one that requires more carefully considered design but that yields greater flexibility.
In this model, the tightly bound user↔app engine connection is replaced by a REST API. Thus the app engine becomes a REST server, possibly embellished with some needed superpowers for accessing host resources. When the app interface is API driven, any REST client technology can be used for the interface, including HTML/CSS/JS clients, native mobile clients, terminal clients, etc. In addition, the client need not be local, making remote-controlled apps almost trivial to implement. Adequate measures must be taken to assure secure and authorized communication with the REST server.
The other change in the above model is that the REST server is implemented in C++. When this is the case, interacting with the host system can be done directly using a wide range of C++ libraries written for this purpose. The choice of C++ here is somewhat arbitrary; it can be any language that supports ready-to-roll support for the system manipulations that your app requires.
The two changes outlined above are decoupled—meaning that either can be adopted in the absence of the other.
One downside to using C++ (or Java, or Python…) for the server part of this approach is that the server must be able to run on the host platform. This isn’t a significant issue with desktop deployment: only recompiling the REST server for each target platform will be required. But it does currently present a problem for mobile deployment as few mobile platforms provide native support for C++ and its oft used libraries. If you plan to target mobile apps, implementing a REST server in a more universally supported language will likely be required.
Follow updates on my wiki.
[^1]: I’m using “app engine” generically here, not as a reference to Google’s App Engine.