The fundamental architecture of the project consists out of three building blocks:

the backbone is a distributed messaging architecture that doesn’t know anything about language tooling, but that is able to distribute messages in a highly distributed environment in real-time at low latency. This messaging works between server processes, between processes running in different cloud environments, and between client applications like browser-based front-ends.

the fundamental concept on top of this distributed messaging architecture is the notion of repositories that can contain projects, resources, and metadata. By using the messaging system, repositories can keep projects/resources locally and sync projects/resources with other repositories running somewhere else.

in addition to repositories and messages, services can connect to the messaging system, can sync data to their local storage mechanism (files, database, whatever), work on that data, and provide additional resources or metadata for the projects/resources.

As a first step, existing desktop IDEs can act as repositories. This allows additional cloud-based services and/or front-ends to be implemented that work on those projects/resources (like editing your project files using a browser-based editor).

As a second step, additional cloud-based services can provide additional features for those projects/resources, ranging from doing “compilation as a service” for error reporting, static analysis, providing smart content-assist, navigation, etc.

This allows developers to connect their existing, still locally stored projects/resources to be connected to the cloud and working on those projects/resources in the cloud at the same time. There is no need to “completely move over” with everything into the cloud. People can choose what and when to use cloud-based tooling while they continue to use their favorite local tools at the same time.

In addition to that the cloud-based services can be implemented in a language and environment of their choice. While a compilation/navigation/refactoring service for Java might re-use the existing Eclipse JDT implementation in a headless way, the same service for JavaScript might want to run on top of a Node.js runtime and re-use libraries such as Tern or ESLint.

Relationship to Orion

The Eclipse Orion project also aims to provide cloud-based tooling infrastructure but the architectural focus is quite different. The main focus of Orion so far has been on browser-based integration and tools that run client-side in the browser. Flux provides a server-focused tooling service architecture that enables both integration between tooling servers, between server and browser client, and between servers and traditional desktop clients. We view these architectures as strongly complementary. Browser-based integration is highly scalable, and enables a more strongly integrated user experience across multiple browser-based tools. Server-side integration enables connection of deeper, long running tools, and legacy tools. Flux will integrate with Orion’s browser-side integration technology where possible, and reuse JavaScript tooling developed in the Orion project. In the long term combining these technologies under a common top-level project may be appropriate.