In my last blog, I talked about the initial technical vision behind Nuxeo what we wanted to do, what we had dreamt to accomplish, our successes and fears. Today, I’d like to explain why we decided to replatform entirely, even though we were quite successful with what we had started to do in 2006.

We were clearly spending too much time addressing low-level technical concerns whereas we should have been focused on solving actual business problems.

Starting a full replatforming is a daunting task, especially with a small team and limited resources. With the evolutions of Zope, we knew we had a complex technical migration in front of us. So, we thought that it was better for us to invest in a full replatforming that would also bring value to our customers and help us grow as a company.

This is why we started to rewrite Nuxeo 5 in Java.

NB: There is actually a reason for the Nuxeo CPS 3 to Nuxeo 5 jump, but that’s probably another story.

From Python to Java: Whaaat???

In 2020, rewriting an application from Python to Java may sound like a heresy. This is how technologies and trends evolve. Back in 2006, writing a server-side application in JavaScript would have been seen as crazy, but moving from a Python framework to a more mature Java ecosystem made sense.

The choice of Java was driven by several factors:

  • compliance with what IT departments were expecting
  • JVM performance, especially with multi-threading
  • existing code and community

Looking back, we have not been disappointed by our choice of Java:

  • it really helped us become accepted as an enterprise-grade solution
  • we were (and still are) very happy with the JVM performance
  • we leveraged a lot of great java technologies and frameworks

To be fair, given the fact that .NET was not open source at the time, there were not a lot of credible alternatives to Java anyway!

At the time, Java applications were built like big monoliths and we had to work hard to preserve the modularity and extensibility we, and our customers, liked so much in the Python/Zope world.

Focusing on our Customers’ Needs

Rewriting from the ground up also meant that we had choices. While our previous product (CPS) was addressing a variety of different use cases, including WCM, we chose to focus Nuxeo 5 on pure Document Management use cases:

  • Digitalization was pushing to more documents, not more web pages
  • Use cases for complex document types and workflows were more Document Management and Digital Asset Management oriented
  • Plenty of good WCM options existed out there, including the future Zope 3

Architectural Principles

While rewriting, we kept in mind what we had learned from doing projects with our customers and we did our best to incorporate best practices from the previous architecture.

Extend and Configure - Do Not Fork

We know “content” is core to any businesses, but no two companies work the same way with content, so customization is always a “must have.” However, it does not mean you need to custom build every time, it just means we needed to provide a configurable platform.

It may seem like a rhetorical difference, but actually it has a huge impact on maintenance and capacity to evolve the application.

In the Nuxeo Platform, we built a configuration and extension model so that there is a clear separation (and hence a clear contrast) between the configuration or extension provided by the project and what Nuxeo, the platform, provides. This design is the fruit of both our Zope experience and our Eclipse RCP/OSGi experience (Kudos to Bogdan, of course!).

This is what drove us to this “everything is a plugin” content services architecture where each project can select what part of the platform they need to use, configure or extend. This initial choice was also key since it allowed us to build the platform progressively, one plugin at a time. Today, that’s one of the key reasons why our customers choose the Nuxeo Platform: our modern and flexible architecture.

Storage Adapters

Leveraging the plugin model, we also quickly introduced the notion of pluggable implementations and storage adapters.
The CPS experience (i.e. Directories) had proven to us that this model was useful. We also made the repository pluggable because we knew that the first implementation (that was JCR-based) might be good enough for a first version but would need to be replaced in the future.

This very notion of storage adapter is what allowed us to adapt the Nuxeo Platform to the various technology evolutions (like embracing NoSQL for example) and to adjust the storage to actual project needs and to Cloud deployment. All this led Nuxeo Platform to become one of the most scalable Content Services Platforms in today’s market.

Meta-Model as an Abstraction

The architectural aspect that was and still is a cornerstone of our architecture is the notion of a documents meta-model.
We wanted to create this abstraction layer for several reasons:

  • the use of a storage adapter required that we define a common abstracted model
  • we knew we could not expect to build everything right the first time and that having an abstraction layer would help
  • technologies do evolve and we wanted the ability to adopt new technologies without having to rebuild or make changes that break features

This meta-model (that hides a part of the technical gory details) is also what opened the way to having a high-level configuration IDE like Nuxeo Studio. And as of today, Nuxeo Studio is key in our platform philosophy. We allow our customers to build customized applications as fast as they need to.

So here it is: this the technical foundation of the Nuxeo Platform as it stands today. Our technical vision from years ago led us to be the most scalable platform on the market today. We’re proud of the choices we had to make and how we adapted the platform to meet the needs of a changing market. We’re proud of having customers who can build apps quickly and integrate new technologies seamlessly, as they become available. From the Cloud to NoSQL or AI, we are proud to provide a future-proof platform to our community.