Ramon Navarro Bosch, Nathan Van Gheem, Timo Stollenwerk: Divide et impera

Plone has a good back end. On the front end lots of stuff is happening with javascript framework, in the brave new Javascript world. The three of us have some personal opinions on the front.

JSON is used to let front and back end talk to each other, for the client and server architecture.

A json rpc api would do a POST to somehost/api, with a method like create_content and give it a type, title, container UID. This is brittle: as soon as you change a detail in this api, you break this. And you do not notice, until someone uses it, unlike a python error that you often discover when the server fails to start up.

You can use multiple URLs. POST to somehost/api/my-folder. Slightly better, you do not need to pass the UID.

You could use all HTTP methods: GET, POST, PUT, DELETE, using the same url with extra parameters. This is what people talk about when doing web apis: REST. An other way to talk about it, is CRUD: Create, Read, Update, Destroy

New package: plone.rest. Register an http method in zcml for an interface of a content item. In your request, tell Plone that you accept json, and plone.rest will return json to you.

You have REST, which is a set of restraints to what such an api should do, and you have hypermedia. This decouples front and back end, in a way that allows you to change the api and without needing to change your client. The client goes to a single entry point and follows links from there. For a proof of concept we used JSON LD and Hydra. You get json with a list of links to members of a folder, including operations that you can do there.

So what is the current status? We have plone.rest and plone.restapi packages.

Ramon: Plone has lots of layers. The rest api is a way to reduce this. Something like PAS (PluggableAuthService) is in essence simple: get the user, get his global and local roles, check which permissions those roles have, and you are done. So why is it so complex? Especially when you use LDAP, making it slow. We are working on getting and storing this info outside of Plone. Then you can use elasticsearch to get roles and permissions. Rely on LDAP and for example docker to get this info. It is an idea. But for some kinds of installations, this may be a good idea, so if you are looking at this, talk to us.

Nathan: page rendering. User accesses a url, python goes to work, and gives an html response. Zope has a Publisher, which in the end gets you this html, using page templates, Chameleon, portlets, etc, some Diazo and Mosaic included, javascript doing some more transformation at the end. Most frameworks like Angular have their own template engines. With Diazo you could actually do the transformation in the browser if you want, there is code for that. We might no longer care about how forms are rendered, letting this be done by a front end framework. For Mosaic, things stay the same, except the rendering that is moved to javascript. So you move a lot of processing over to the browser. Plone server runs REST api, static css and javascript served by apache or nginx, javascript doing the real rendering. Problems: page loads would not include any html, so that is bad for SEO. But you could use NodeJS for this. And search engines are playing nicer with javascript.

Further topics. Forms done by some javascript framework. Search: not ZCatalog but solr or elasticsearch. Diazo: will we still need that? Dexterity will most likely stay: we will still need content types. Hackability, keep that in mind.

This is work in progress. We are discussing ideas. We are not saying that Plone 6 will look like this. These packages will work with your existing Plone sites and not break anything, so you can test this with whatever javascript framework you like.

Javascript frameworks are a moving target: yes, that is hard. For some projects you may want to use React, for others Angular 1.3 or 2. We will provide the restful api as common ground. People can build on top of that. We are not sure this is where the web is going, but we are pretty sure this is a good way that will work.

We have a good front end that is great for a lot of use cases. We are not breaking that. But we are adding possibilities.

Martin: Web sites are generally becoming more complex, with more features, plugin possibilities. If others can talk to you this helps. What matters is accessibility and integrateability, making it nicer for others. If we design the api really good, it can make Plone really successful.