Building a desktop OpenPaaS application
Last week, a part of the OpenPaaS team met in Agde during a one week long barcamp. The goal was to explore the Offline mode for our web application, and to try to get an Electron build out of it. This article details the steps and results of the later experiment.
Electron is simple
I already knew that, and has been once again astonished by the simplicity of the Electron framework. It’s so simple to take a website and have it run in local ! Although simple, Electron is really powerfull, and the fact that you have, in the browser windows, Chromium environment alongside NodeJS is simply magic.
OpenPaaS is not simple
OpenPaaS is targeting a Cloud system, where administrators can add applications (we call them modules) into the PaaS. And of course that should be done without a restart of the server. Which means a lot of things in OpenPaaS are done dynamically, on the server: what JavaScript files to inject into the frontend app, what Less(css) files to concatenate to build the final CSS file, …
To make this happen, modules register their assets during their deployment phase (indeed, modules got a lifecycle in OpenPaaS thanks to the AwesomeModule system). So that happens programatically.
When creating an Electron build, this is not what we want : we don’t want to have to launch an OpenPaaS server to get the assets that we have to put in the Electron application. That lead us to add to the OpenPaaS modules some declarative syntax so they can expose their assets. And that was a lot of work.
Another big task we did is being able to set the REST API server URL globally for the system. When you serve your pages through a server, there is no problem: the REST calls are mostly done to that server. In a desktop application, that is not the case anymore: we have to set the server base URL and propagate it across all modules.
And then they were some more minor fixes, like ensuring we always use Angular ui-router ui-sref directive instead of the classical href=”#…”, because otherwise Electron treats it as a call to the local filesystem “/” path. Another fix has been to track ng-src changes and update the resulting URL to, here again, set the full URL of the link. Hopefully we already did it during the development of a Cordova application based on the OpenPaaS framework.
Building native packages out of Electron is simple
Or maybe it’s complicated, but we used the awesome electron-builder utility, and that allowed us to quickly have packages working on Linux and Windows. For OSX, it seems like we need an OSX… That’s a story for another day.
And so we have…
… a clean build system that allows the developer to choose what modules he wishes to include into the application, as well as what server to connect to, and then everything happens through 3 command lines ! We are proud of the result we achieved in 5 days of work, and we’ll now work to include the Electron related code into the main OpenPaaS codebase.
Conclusion
Electron is a wonderful framework, working with it has been a real pleasure, and the pitfalls we met on our journey have all been resolved without dirty hacks. I’m glad Open Source communities build such great frameworks, and I’m proud to be part of that ecosystem, and to be able to give back, because our company develops real free Open Source Software.
