David Glick - Greater Than the Sum of the Parts

Lessons from integrating Pyramid, React, and Plone (and elasticsearch, and Salesforce, and a payment gateway, and...) Quoting from the Plone conference site: "The Volunteer Management System (VMS) is a tool that Jazkarta built for Washington Trails Association to manage volunteer sign-ups for helping maintain hiking trails in the state of Washington. It allows staff to schedule work parties, volunteers to find and register for them, crew leaders to access information about their crew, and land managers to report on work that was done in their region."

The tools you use matter. So use the correct tools.

So at the start, we had the wta.org site, and Salesforce, and vols.wta.org, which was basically a bunch of ten year old scripts.

We could have built everything in Salesforce. It has all kinds of options for doing this, but there are all kinds of restrictions.

We considered Plone. All user accounts were already in here. But we did not need a lot of content management.

On the front-end we used ReactJS. This communicates with Plone for content and with Pyramid for the volunteer management. Pyramid interfaces with Redis, ElasticSearch and Salesforce.

With Pyramid, the view configuration is very close to the actual code, so you don't need a separate zcml file like in Plone. There are no globals, which makes it easier to write isolated tests. Views are easier to test because they return a dictionary instead of a complete html response.

Pyramid is a framework that is good for writing frameworks. We needed to write some infrastructure ourselves, which is nice to do in Pyramid. For example, with config.add_request_method we made a method available on the request to access Salesforce. We registered an exception view to gracefully handle exceptions for either html or json.

With Pyramid, batteries are available for cheap:

• pyramid_chameleon
• pyramid_layout
• pyramid_cachebust
• pyramid_mailer

As special deployment bonus: we were not using a ZODB, so no ZODB cache was needed, so memory requirements were low, so we could use lots of threads to handle moments of high load.

It is not perfect, for example there is no automatic csrf protection like in Plone. Some assembly is required: Plone has lots built-in and in Pyramid you need to do more yourself, for example setting up logging.

We used the py.test framework, which makes it really easy to define fixtures. There is some magic, which not everyone likes. Assertions are easier to debug, giving you more feedback. We used factory_boy to provide fixtures. [See a talk at PyGrunn earlier this year, by Oleg Pidsanyi. Maurits]

We used http://locust.io for load testing.

React was our chosen Javascript framework. I like that it is declarative. You can focus on what is displayed, not how. A lot of changes, like toggling a checkbox, happen automatically.

We have shared navigation between Plone and Pyramid. The navigation is done in Plone, and we created a json endpoint in Plone that Pyramid could call.

We needed to think about Cross Origin Resource Sharing (CORS), with all kinds of headers. These days I would look at plone.rest and how it does this.

Single sign-on. Pyramid redirects you to Plone, where you can login, and with a token you are then logged in to Pyramid.