Everything Must Go

Traefik

The application design brings about some challenges to the underlying network, and the oCIS developers have chosen the Traefik framework [7] to tackle those. Traefik automatically load balances between the different instances of microservices, takes care of automated SSL encryption, and allows for the additional deployment of firewall rules.

The split between the back end and the front end add additional advantages to oCIS. In fact, actions triggered by the user by means of ownCloud Web are completely decoupled from the ownCloud engine performing the respective task in the back end. If a user manually starts a virus check on their file(s) stored in ownCloud, they do not have to wait for the check to be finished. Instead, the check itself happens in the background, and the user only ever sees the result once the check is completed – the principle of concurrency at work.

Extensions as Microservices

Like other web services, ownCloud also supports extending its capabilities with extensions. oCIS doesn't change that, but it is promising to tackle a well-known problem, especially with community apps. Apps of unknown origin can cause trouble in the server and hamper updates and often have negative effects on the server's overall performance. The new oCIS gRPC-based architecture makes it much easier to create additional extensions spawned alongside the already existing microservices. Because the API is predefined by gRPC, all developers really have to do is create a microservice featuring the desired functionality that can be controlled by gRPC. Traefik will, on a per-case basis, ensure that newly deployed add-ons are automatically added to the existing communication mesh. For users and third parties interested in ownCloud, this means that a flood of additional ownCloud functionality will likely start to pour in for oCIS.

Arbitrary Extensions

The oCIS developers make it very clear that they want to support such extensions, and they are even making it very easy for developers to integrate custom modules. Their documentation [8], for instance, contains a detailed explanation of how to write oCIS extensions, along with code for a real-world example.

Said documentation suggests that writing an oCIS extension is not super-complex for experienced Go jockeys. Three major components are required: the server providing the extension's functionality through a gRPC API, a so-called "greeter API" to serve requests to the extension from the outside, and, if desired, a separate component integrating the extension into ownCloud Web.

The greeter API integrates with the oCIS server itself to allow commands to the server to be caught on the API of the oCIS instance. It communicates with the server through gRPC. The Hello World example [9] in the oCIS documentation illustrates this clearly: For instance, the command received through the oCIS API could be for Hello World to be returned as the result of an oCIS API request. The greeter API would catch that request, trigger the corresponding action over gRPC, and deliver the return value. The web interface can be used to send the Hello World request to the greeter API.

Although a simple Hello World is an oversimplified example, the flow of commands brought up by oCIS developers also allows for highly complex operations to be performed by oCIS extensions. Of course, all oCIS extensions will still benefit from Go's concurrency functionality and its default optimization for performance purposes.