Nathan, Ramon and Eric: Status of Guillotina

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.