About

As the Web evolves, so do the frameworks that we use to work with the Web. Guillotina is part of that evolution, providing an asynchronous web server with a rich, REST-ful API to build your web applications around.

It is designed for building JavaScript applications. It is an API framework, not a typical template-based rendering framework like most web frameworks (Django/Pyramid/Plone). What we mean by this is that Guillotina will not generate HTML out-of-the-box for you. It is designed to be consumed by JavaScript applications that do the HTML rendering.

Features:

• REST JSON API
• Built-in authentication/authorization, built-in JWT support
• Hierarchical data/url structure
• Permissions/roles/groups
• Fully customizable permission/roles/groups based on hierarchical data structure
• Robust customizable component architecture and configuration syntax
• Content types, dynamic behaviors
• Built-in CORS support
• JSON schema support
• PostgreSQL and CockroachDB drivers
• Blobs

Guillotina is built on the lessons learned from great technologies of the open source projects Plone, Zope, Pyramid and Django.

Inspirations:

• Plone/Zope’s hierarchical data model
• Pyramid’s decorator-based auto-discovery application configuration syntax
• Django’s global application settings style syntax
• Zope’s component architecture for building robustly customizable applications
• Plone/Zope’s security model
• JSON Schema

Lessons Learned (from said inspired frameworks):

• Trade-offs for the sake of performance is okay
• Too many complex dependencies causes difficulties in management and upgrades
• It’s okay to fork dependency packages

History lesson

In the beginning, there was bobo.

bobo was what Jim Fulton called his initial idea of mapping objects to web urls. It’s an old idea. A beautiful idea. The developers of Guillotina think it’s the best possible way to conceptualize most content-centric APIs and organization of how your web applications think about data or their APIs.

Think about this simple example. Assuming you have the following dictionary:

{
  "foo": {
    "bar": {}
  }
}

The corresponding urls for a site based off this dictionary would be:

• http://localhost:8080/
• http://localhost:8080/foo
• http://localhost:8080/foo/bar

And so on… It’s a simple way to build APIs from data around a hierarchy (or tree).

Extrapolating this concept, Jim Fulton also built the ZODB package. This was a complete database built on serializing Python objects using the pickle library. Then, frameworks like Zope (and eventually Plone), used this database and the bobo style of publishing objects to URLs to build a framework and CMS around.

Forked dependency packages

Guillotina has eaten a few packages that would have otherwise been dependencies.

The reasons for forking are:

• Required to support asyncio
• Provide tighter fit for framework
• Make installations less painful and error-prone
• Groking framework is easier when there is one package to import from

Forks:

• parts of the ZODB data model: we’re on a relational storage model now
• plone.behavior
• zope.security
• zope.schema
• zope.component/zope.configuration
• zope.dublincore
• zope.i18n
• zope.lifecycleevent
• zope.location
• zope.event

What it isn’t

• Guillotina is not a replacement for Plone
• Guillotina is not a re-implementation of Plone
• Guillotina does not implement all the features and APIs of Plone

It could some day with the guillotina_cms package but replacement of Plone is not the goal of Guillotina.