DRAFT: Replace Plone as a rest API with Nick

[robgietema]

PLIP (Plone Improvement Proposal)

Responsible Persons

Proposer: Rob Gietema

Seconders: Victor Fernandez de Alba, Dante Álvarez

Abstract

The Plone content management system has been around for over 20 years and in that time a lot of functionality has been added and removed to the code base, which means a large codebase (~1.250.000 lines of code) needs to be maintained. Since a couple of years Plone moved to a headless solution using Volto as a frontend solution where Plone acts as an API service. Because of this a lot of functionality is not needed anymore in Plone.

Since switching to a JavaScript frontend a lot of new developer have come in who have no, or little knowledge of the complex Plone stack and most of them also don't have knowledge of the Python programming language.

Nick is a headless content management system written in Node.js which has an api which is compatible with the Plone restapi. It has a small (~8.800 lines of code) codebase and provides all CMS functionality which Plone provides including the extended permission system.

Motivation

The motivation to write Nick and use this as a backend is that it uses the same language as used in the current frontend (Volto) which makes it easier for new developers to contribute to the project.

Because Nick is written in Node.js it is asynchronous by default and provides much better performace (~4x writes and ~100x on bulk operations).

Assumptions

It is hard for new developers to start working on the Plone backend because of the large stack.

Most frontend developers don't have knowledge of Python.

Maintainance of a large software stack is costly.

Proposal & Implementation

Our proposal is to replace the Plone backend with Nick, a backend written in Node.js which is compatible with the Plone rest api.

Deliverables

• Backend with a rest api compatible with plone.restapi
• Clear migration path for the website data
• Documentation of all the endpoints
• Documentation and training materials of how to customize the backend

Risks

Cost of migration

Participants

Rob Gietema, @robgietema
Victor Fernandez de Alba, @sneridagh
Dante Álvarez, @danalvrz
Steve Piercy, @stevepiercy

[stevepiercy]

More Deliverables to consider:

• Transfer ownership of the repository to the Plone GitHub organization.
• Establish trusted maintainers.
• Add deployment of the demo site to the @plone/ai-team.
• Create a Cookieplone template backend-nick.
• Decide whether documentation remains standalone, integrated into Plone Documentation, or both.
• Consider switching documentation to use Plone Sphinx Theme.
• Create a Discord channel #nick.

And, of course, discuss with the Steering Circle as soon as possible.

[tkimnguyen]

Mind blowing and audacious! Another risk to consider: we will be cast out of the Python orbit… strange to consider.

[ericof]

Another important point: The restapi still lacks (or does not care about) most features we have in Plone and Zope, so claiming Nick is compatible with the restapi hides the complexity involved in this endeavor.
We also need to remember that Guillotina claimed, few years back, the same goal of replacing the Plone backend.

[davisagli]

I think this is an interesting proposal to keep in mind, but too early to consider seriously. I think it could be considered more seriously at a point in time when multiple Plone providers have independently chosen to use Nick and successfully completed projects with it. (And I don't mean this as stop energy; it might already be a reasonable choice for some projects.)

Another important point: The restapi still lacks (or does not care about) most features we have in Plone and Zope, so claiming Nick is compatible with the restapi hides the complexity involved in this endeavor.

@ericof Which specific features are you missing?

We also need to remember that Guillotina claimed, few years back, the same goal of replacing the Plone backend.

This is not quite the same situation, since Nick takes backwards-compatibility more seriously than Guillotina did.

[petschki]

"Improve Plone by removing Plone" ... maybe the marketing team wants to think about the wording here?

[stevepiercy]

• Documentation and training materials of how to customize the backend

I'm not sure what "customize the backend" means. Does it mean extensibility and add-ons?

Are there any add-ons for Nick?

too early to consider seriously.

That depends on what one considers Nick to be now and in the future. A complete replacement of the Plone backend is premature now. However it should be considered as an alternative to it now, and a potential replacement in the future, if ever.

As such, I would suggest the following text change from:

Our proposal is to replace the Plone backend with Nick, a backend written in Node.js which is compatible with the Plone rest api.

to:

Our proposal is to provide an alternative backend for Plone using Nick, with full feature-parity to the existing Plone backend.
Nick is a backend written in Node.js, which is compatible with the Plone REST API.

@petschki @robgietema @davisagli @ericof would this be acceptable?

[yurj]

In the Plone backend code there are tenths of thousands of lines, with hundreds of corner cases. How do you think you can replace them? What about advanced Plone features don't covered by REST API? Have you replaced Dexterity and ZCA with few lines of javascript?

[stevepiercy]

So far I haven't seen any cited specific features missing from Nick and Volto that currently exist in the Plone backend. I think a distinction must be made between the implementation of a feature and the feature itself.

There is mention that there are features in Plone backend that are not implemented in REST API, but I see no specific feature cited.

Dexterity is an implementation of the feature Content Types, which both Nick and Volto have.

ZCA is an implementation of a registry, again which both Nick and Volto have.

IMO, the 1.25M lines of code in the Plone backend is not a feature, but a burden. Since you can do the same things in 8.8K lines of code, it's freedom and liberation.

[sneridagh]

Let me leave here some questions.

Would it be so hard to consider this PLIP serious and possible? Who thought that plone-react, 7 years later, would have been able to reach the point where Volto has reached? Who would say back then, that finally, we chose and bet on the right technology, the one that won in the industry for dealing with UIs? That we could infuse it with the wisdom and knowledge that we gained through the last decades building CMSs. That we could build a unique and sustainable add-on system, where no other tool in the JS ecosystem has.

I was present ten years ago in the second Bristol Plone Conference open space where Martin Aspeli gave people a reality check stating that rewriting Plone was not possible, when people proposed that we should rewrite Plone in Pyramid.

Well, are we not half way for that to happen? Who says that, if we want to, in another 7 years Nick is not as powerful and feature rich as Plone backend is today? Rob already did it once. The Plone community already did it once. Its name is Volto. Do you really think that we are not capable of doing it again? The point is not in the amount of existing code, but in the wisdom in it and how we transform it on our behalf.

@yurj the Plone community have been implementing Plone projects with Volto since 2017. Which Plone advanced features that REST API does not cover are you missing? Because, this didn't stop us to make business with it, and if it would have, we would have implemented them.

[mauritsvanrees]

Volto did not replace Classic UI. Classic UI is still there in Plone 6 and will be there in Plone 7.

In the same way, Nick will not replace the Python backend. The Python backend is there in Plone 6 and will be there in Plone 7 as a good and supported option. So I object to the word "replace" in the title of this PLIP.

But sure: having Nick as a viable option would be nice. It can open up Plone to new audiences. Then we will have to see how many people jump on board that train. People could sprint on it.

A first step could be to move the repository to the plone organisation on GitHub. Are you planning that?

As for missing features in Volto/plone.restapi: I know that several control panels are missing, at least Discussion and Caching, and more according to this issue. But that should not be rocket science to implement. Once we really split out Classic UI from the Python backend, more missing features may become clear, but I have just finished a major project with Volto and that is working fine.

I just tried out Nick for the first time. It is very fast. The basis seems to be there, but I have not seriously tested it, so it is hard to say what would be missing. Also at this point I have no idea about how secure and stable it is. I have only glanced at the code. I count 12000 lines of code in the src directory. At that amount I can't imagine that it covers all corner cases that the current backend does, and offers the same flexibility and pluggability, but that may be my lack of imagination. It sure is impressive what you can do with such a small amount of code, and for newcomers this makes it way easier to understand than the current backend. So kudos!

[sneridagh]

@mauritsvanrees +1 for rewording "replace" and reformulate the whole story to "complement" and "sum up".

[ericof]

First of all, I want to avoid the whole "stop" energy. Sorry if it came across like that.

tl;dr: I think Nick is no real replacement for Plone anytime soon. Nick could be an option for smaller sites, but larger deployments use features we have been supporting and hardening for more than 25 years.

Concerns

So, let's address my specific concerns here

plone.restapi

@ericof Which specific features are you missing?

plone.restapi hides the complexity of Plone core from the frontend. Some examples of features of core that are not available:

• Authentication mechanism (PAS is a very good idea, and its complexity also serves many corporate clients with legacy systems and crazy internal rules)
• Content-types framework with reusable behaviors
• Support to multiple workflows to be registered
• Clear add-on contract allowing you to replace parts of Plone with other solutions (PAS, catalog...)

(Does Nick support content rules already?)

Besides that, the restapi, today, does not have (from the top of my mind):

• Constraints support
• Placeful workflow support

Dropping our entire backend add-on ecosystem

I know most people use only the basics of Plone, but for some of us that need advanced features, the existing add-ons are a great way to be productive, also it is our way of sharing complex features to the community. Moving from Python to Javascript and having to rewrite everything from scratch is not a real option.

Cost and time involved

To make Nick a viable option would require a major investment in terms of time and resources, which we, as a community, do not have.
If companies (more than one) decide to build projects on top of Nick and invest time there, perfect, otherwise it will be a low-end alternative to what we currently have.

IP, Trademark, and so on

Some important steps:

• NickCMS needs to be donated to the Plone Foundation: Code and trademarks
• NickCMS codebase needs to be under Plone Foundation / Community control
• The Plone Foundation needs to make sure NickCMS is a trademark we can get domains, social media handles, and other trademarks

Summary

NickCMS could be a good low-end alternative to the current stack. We could replace GuillotinaCMS from the volto repo with it, but it is not a real replacement for Products.CMFPlone

[ericof]

Our proposal is to provide an alternative backend for Plone using Nick, with full feature-parity to the existing Plone backend.

Again, full feature-parity with plone.restapi is not the same of full feature-parity to the existing Plone backend