Guillotina is a full stack REST API data framework to build applications. It is built on AsyncIO. We think it is simple, but with batteries included. We are inspired by the best of Python: ideas from Pyramid, Plone. We want to keep to the spirit of the Plone community. We want to build tooling so that creating a front end on top of Guillotina is easy.

Everything is defined in a JSON Schema / Open API 3 / Swagger. We have hierarchical content with security, so very Plone-like. Transactionally safe with PostgreSQL. Pub/Sub, indexing, lots more.

We released Guillotina 5 this Summer, requiring Python 3.7 or higher. AsyncIO has matured there, with a great context vars api, letting us simpligy our code.

Use cases. What are we using it for in production?

• CMS.
• Data Framework mix. Secure personal data and application data, gathered automatically. Reports. Partially data that needs to be searched: pgcatalog and ElasticSearch. Partially data that needs to be secure and massive: cockroach.
• Machine learning processing. I often meet data scientists that always want a csv export. That takes too long for so much data. So have a front end that directly accesses the data in Guillotina, without needing an export. We use pickles to store data, and now this can contain numpy arrays.
• Web / Mobile applications.
• Knowledge Management. At Onna we work with some companies that have really big data, in emails, Jira, other tools. We can plugin this information from different sources and index it fast, because of AsyncIO.

How is Guillotina different from other frameworks?

• First: AsyncIO has won. Django is also moving towards this.
• Django: great OOTB feature set, lots of tooling, add-ons, support. Not a great REST API framework, and still comes from the days of server side templates.
• Pyramid: no batteries included.
• Plone: full feature CMS. Less good for large amounts of structured data. ZODB cannot really use AsyncIO.

Deployments:

• Guillotina is good for large amounts of data, but also for small amounts.
• The memory footprint is really low, again due to AsyncIO. If you use ElasticSearch for indexing you need much more memory.
• PostgreSQL has lots of tooling around it.
• In most cases we have three Guillotina processes, accessing 1 Postgres database.

Front end:

• Volto has 80 percent compliance with guillotina_cms.
• Grange (French for a barn, where you put all your farm tools).

Grange assembles your application fast. A lot of ready to use components.

Powerful principles: - traversing - state management - view overriding

Featureful:

• Pastanaga-based UI library
• Dynamic form generation, using the schemas that you get via json from Guillotina
• Standard views and components, like breadcrumbs and navigation
• i18n
• npm install @guillotinaweg/grange. This covers the standard CRUD scenario with any schema, and you only need to declare your custom views.

Roadmap:

• Guillotina 5 will be LTS.
• Guillotina 6: ASGI, dbusers in core, tooling, more behavior APIs. May have longer alpha phase.
• Some ideas for a Guillotina Object Server in Rust.
• Protobuffer instead of pickles, as pickles tie us to Python.

At Zest in The Netherlands we have several clients in Flanders, a part of Belgium. One is a government organisation for the environment. One of their sites is about water management. Information about water levels in separate areas, floodings, pollution, etcetera. The country has several partially overlapping governments, and water is flowing through all of them. So it is a bit complex.

For a new part of the site, they said: wouldn't it be nice to let Plone help in getting the next big report with plans for the next six years for the government together? So the report should be viewable as web pages. But wouldn't it be nice to also let this generate the official Word document?

A business analysis followed, with requirements and scope:

• collectively edit it
• seperate between core and background information,
• export only the core going to a main PDF document

Ah, PDF export. Don't we love it? Always tricky, always corner cases, always too many pages, locking up your Zope server or crashing the export. For another site also dynamic graphics, table of contents. So: alarm bells went off. And do we really need PDF, can't it be something else?

Begin with the end in mind. Do I even want this project? Do we have the required skill sets in the team?

So what did we do? We made an MVP, a Minimum Viable Product. A prototype. Can we do all the parts of the process and have a basic document? Let the client test early to see we are on the same page.

Our internal customer was used to writing lots of plans, but a business plan was something else. Lots of things in there that would be nice. But which of those are really absolutely necessary?

Actually, the customer already made a mockup in a website. We had a meeting, things changed, new plans.

In the end, the Word document did not seem that much of a problem. But our initial main structure with two content types was too rigid. We simplified to one content type, and it was fine. Some different views for the content type to choose from.

We use:

• plone.api to find content.
• beautifulsoup4 to analyze the html.
• python-docx for generating a Word document.

Interesting extra problems were internal links, and later footnote support. Not really supported in python-docx yet, but with some lower level code it worked.

Risk: some html things may be too difficult to put in Word reliably. But they can edit the document later.

Something extra: we use pas.plugins.ldap and it is working smoothly now. We have some code to migrate from plone.app.ldap to this, and want to publish that.

Remark from Andreas: with a similar project we discovered that it was difficult for editors to make a section from say level 1.2 to 3.2 in the default Plone UI. So we made a special view for that. And watch out: tricky to lock everything down in TinyMCE.

Question: did you try collective.documentgenerator?

Answer: no. The things we found, were too big and generic.

We will go through the Volto training in about forty minutes.

To create a new Volto project, you need nvm and yarn, and then type the following:

$ npx @plone/create-volto-app my-volto-app

• You can override public resources like the logo, styling, etc, from Volto.
• Volto uses Semantic UI. For example, it uses the BreadCrumb component.
• Theming: in theme.config you use the Pastanaga theme by default, but can pick and choose other themes for some elements. You can do a lot of theming just by changing some variables in less. less instead of sass is needed by Semantic UI for conditional imports.
• You can override a component by copying the folder structure of that component from Volto to a customizations folder.
• We use yarn i18n to extract all translatable strings into .po and then .json files.
• Volto uses the DraftJS rich text editor. You can configure the buttons that are shown.
• As is usual in React, Volto uses actions and reducers based on Redux.

If you want to learn about Volto, see the full Volto training.

Question: why don't you use React hooks?

Answer: This was introduced one and a half year ago in React, allowing to use more functions instead of classes. Quite cool. But then we would have two ways to do the same thing, and we try not to do that in Volto. We try not to jump on those hooks right away. If we switch after a while, we want to switch the whole code base.

Question: how do React developers experience this?

Answer: we did some presentations in React conferences. Reaction is that it looks really nice, we get positive feedback. I wrote a small reference implementation of the needed backend in node, and was finished in a few days, so people can do that too.

I start with some community updates from the past year.

• We have six new foundation members: Christine, Thomas, Fulvio, Rikupekka, Kim, Stefania.
• We have added Zope to the Plone Foundation.
• 35 new core Plone committers.
• Nine funded sprints.
• There was a sprint in Barcelona this year from the Automization and Infrastructure team. They worked dist.plone.org and other core servers, rewriting Ansible scripts. They are looking to do two or three sprints next year, and they would like more people to join. You don't need to be an expert.
• Google Summer of Code: Gatsby and Guillotina work was done.
• Google Season of Docs: improved Volto documentation.
• A lot more people have been following Plone trainings. The trainings are available for free via https://training.plone.org. Right now 17 different courses available.
• Steve McMahon is stepping down from creating Plone installers. Please step up, and he will gladly help along in a transition period.

Python 3:

• Python 2.7 will not get security patches anymore from 1 January 2020. So for Plone it was really important to run on Python 3. That now works: first Zope was upgraded, and now Plone 5.2 runs on Python 2 and 3.
• Archetypes is now optional. It will not work at all in Python 3, so this is your wake-up call to update your code to use Dexterity.

Other changes in Plone 5.2:

• Plone 5.2 gives us plone.restapi. This means BYOFE: Bring Your Own Front End. So if you want, you can create an own front end to talk to Plone as backend.
• We have dropdown navigation.
• The login code was rewritten, to not use the old skin layers anymore, but use browser views. Much better testable.
• Theme improvements: static resource refactoring, removed old css/js resource registries, first main content then sidebar content.
• Integrated Products.RedirectionTool so you can manage redirects.

Other:

• Guillotina was started as a reimagining of Plone. It is really a separate project now. New version 5 has PostgreSQL indexing and search, pub/sub, there is Guillotina CMS.
• The new Pastanaga UI is evolving. We have a design document for Plone now.
• Volto: React-based front end that uses plone.restapi to talk to Plone. It uses the Pastanaga UI. Dramatically simplified rich text editor. It uses modern front end development, instead of building our own tools. We are improving the learning curve by removing Plone from the learning curve. That is awkward to say for me, but it brings more people in, front enders who can customize Volto. Volto uses JSX (JavaScript Expressions), Semantic UI. Significantly faster than our current built-in front end. And Volto works on both Plone and Guillotina. It is almost on par with the existing Plone UI, but some features are missing, like content rules and several control panels.

Volto helps with decoupled development. Plone is about keeping your data safe, having migrations. That is all backend stuff. We need a measured pace for this. The front end needs to evolve much faster, which Volto can do.

Challenges and open questions.

• Can we move to one content type, that can behave like an event, or a page or a folder? Does that solve problems or introduce new ones? Timo will talk about that.
• UI support: how much of the classic Plone UI do we keep around? Do we put all effort into Volto instead?
• What is "Plone" now? We have said: Plone is a CMS, a framework, a product, a community.
• We can say: Plone is the API contract: You can use Plone on top of Zope, or you can use Guillotina, you have an API on top of that, plus a front end. But what is important is this contract: security, flexibility, extensibility, user experience.

Since the end of 2017, there is a new version 4.0 of collective.recipe.backup. There are lots of changes since version 3.1. Let's see some of the highlights.