Livingdocs software architecture
Our enterprise customers often ask us for a detailed overview of the Livingdocs software architecture. Livingdocs is a backend CMS which means that you have full control over how you present your content to your readers and at the same time you don't have to worry about how documents are edited and managed.
Use the zoom controls on the image to see details
The main idea of the backend CMS is the dotted red line in the zoomable graphic above: the separation of what Livingdocs manages and what you as a customer can add to it. The bottom line of this approach is very simple. As a customer you create a design in HTML and CSS and split it into sensible components. This design is fed to Livingdocs and your editors can start using it right away within the Livingdocs user interface. We created a boilerplate design that you can use as a starting point for creating your own Livingdocs design.
At the other end of the publishing pipeline, you can build a delivery app that takes Livingdocs articles in HTML or JSON and presents it to the user. This gives you full control over how you build your delivery app, be it a website, a native app, or even completely different formats such as a newsletter. We have a push as well as a pull API for all Livingdocs articles. To get you started quickly, we provided a boilerplate delivery app for websites in Node.JS that we also use for our own blog.
Neither a document store nor CMS is necessary to run your publication with Livingdocs. Many, especially larger customer, still want this though to connect third-party systems or build up archives. The integration is simple and can be done similar to the delivery app over our content APIs.
Service customers will never need to know more about the Livingdocs architecture than this. Livingdocs will just work for them. Enterprise customers on the other can customize all Livingdocs components including elements of the user interface. The subsequent section will detail on these use cases as we have them for example at NZZ.
Internally, Livingdocs relies on 3 main components: a framework (Livingdocs Framework), a user interface (Livingdocs Editor) and a server (Livingdocs Server). Enterprise customers get a custom fork of the editor repository. Both, the server and the framework can be included in a custom project via npm. Customers have full source code access to the projects in order to build the customizations they need.
From experience we detail 2 forms of often-used customizations: new (possibly interactive) user interface elements or integration with third-party systems for the editors.
The first customization use case can for example be a specialized interactive table component that generates the financial statements of company xyz. Livingdocs provides a plugin system to the user interface for such cases. As an example, we build an image gallery with this plugin system that helps you get started. The user interace is written in Angular.JS and basic Angular.JS knowledge is required to write plugins for the user interface.
The second use case for customizations is server-side proxies. A common example is the need to integrate an existing authentication service in a corporation with Livingdocs. In that case you would write server-side proxy endpoints that use your authentication service instead of the one Livingdocs provides. The user interface does not need any customizations in this scenario. At NZZ we build an integration with auth0 that can be a guideline on how to do such an extension. The server is written with Node.JS and basic knowledge in Node.JS is required to write server-side extensions or proxies.
We picked 2 common use cases to visualize how you can customize Livingdocs in an enterprise plan. These are of course not the only ways in which you can work with Livingdocs: you have full source code forks so you can basically do whatever you want. In any case we recommend our customers to check with us before doing major updates and discuss where and how to implement customizations so that the upstream compatibilty to new versions of Livingdocs is always guaruanteed.
Livingdocs uses modern web technologies
You may realize that there are still more boxes in the software architecture graphic from the beginning. Livingdocs relies on many modern web technologies and services to drive a cutting-edge editing experience.
Images are optimized and hosted with Amazon's S3 service and delivered using the responsive image service resrc.it. Resrc.it makes sure that images are always delivered at the optimal size for the viewer's device. So never again worry about 4MB images delivered to a mobile phone.
To give editors real-time features such as our real-time collaboration, we use pusher as an optional communication channel between our server and the user interface. As an enterprise customer you can of course use pusher to integrate other real-time systems such as a chat.
Last but not least we use elastic search to index all Livingdocs documents. This gives you extremely powerful options for your delivery apps. You can use any search query and/or tag indexes to requests Livingdocs documents and generate start and teaser pages from them. This allows you to provide personalized landing pages for your readers just as well as powerful search and navigation features.
The Livingdocs architecture is continually evolving. We'll keep you up-to-date if new components enter our eco-system. The components in place today are here to stay though and you can fully rely on them when building your publication with Livingdocs.