1 of 91

Open Source City CMS:

Gov data content as an API

2 of 91

What’s Inside

How did we get here?
Headless CMS
Putting the user first
Wagtail CMS
GraphQL API
Static Site Generators
React & Reusable Components
Devops & Containers
Working in the Open
We need your help

3 of 91

American Folklore

0

4 of 91

5 of 91

6 of 91

What’s a Hessian?

7 of 91

The Texas Version

By Texas Legend, Public Domain

8 of 91

Why am I talking about a headless horseman?

9 of 91

Headless CMS

for alpha.austin.gov

10 of 91

How did we get here?

1

11 of 91

tinyurl.com/oa-austin-chron

12 of 91

open-austin.org

13 of 91

14 of 91

15 of 91

16 of 91

17 of 91

18 of 91

Headless CMS &

Gov data as an API

2

19 of 91

Decoupled or Headless CMS

Public pages are not created by the Content Management System (CMS). The HTML, CSS, JS generation happens through a separate service.
Public pages get data from an API feed provided by the CMS.
Admin site for editing content is managed by CMS.
Think of it like your CMS as a database.

20 of 91

21 of 91

Microservices

Independent applications that do only one thing and do it well — with the tool most suited to the use case and technical context.

22 of 91

Too big to fail

23 of 91

24 of 91

25 of 91

26 of 91

Putting the user first

3

27 of 91

“The People are at the top of the org chart.”

“Put Residents First” is the 1st of our 6 Digital Service Values.
This orients our priorities as a service organization.
Our dev team is making tools to serve the user researchers, who serve the content editors, to serve the public.

28 of 91

Research

29 of 91

“I don’t actually read everything. �I just go through and I see if there’s an easy answer.”

- Robert

30 of 91

31 of 91

Residents find current content too lengthy and complex, and content is not accessible to all.

32 of 91

AustinTexas.gov Pages Reading Level

Maximum reading level recommended

33 of 91

Austintexas.gov has 11,000 pages and 10,000 documents such as PDFs.

pdf

34 of 91

Content, not technology, is the hard part

The real work is around making sure residents have a great experience.
The way to do that is to support content authors.

35 of 91

Build a Platform People Want to Use

Website Users

Public Users
CMS Administrators

Developers

Build on Data

Public API

Build on Platform

Open Source

Other Cities

Adapt Platform for their Needs

36 of 91

Wagtail CMS

4

37 of 91

Building on an open source platform

Customizable

Expandable

Portable

Supported

38 of 91

Conversations with our peers

We’ve had 2 conversations with cfpb folks about Wagtail
We talked to Boston.gov & Mass.gov about Drupal 7 vs Drupal 8
We talked to the Vets.gov about how they use React to build forms

39 of 91

Digital Services Playbook

“The American people expect to interact with government through digital channels such as websites, email, and mobile applications. By building digital services that meet their needs, we can make the delivery of our policy and programs more effective.”

40 of 91

The Zen of Wagtail

Zen of Wagtail Article

41 of 91

Wagtail ecosystem

Developed in Feb ‘14 by Torchbox, agency based in the UK.
Torchbox managed big public sites with Drupal.

“You don’t get fired for choosing Drupal.”

Made with Wagtail:

United Nations, Oxfam, NBC News, 18F, FEC, cfpb, UK Gov, NHS, NASA, Intel, Wharton, City of Helsinki, Municipality of Anchorage, Open Canada

Our team is already contributing back to the Wagtail open-source project.

42 of 91

Django/Python ecosystem

Django is the underlying MVC framework.
Python community

Common language for CS 101
Widely used in GIS, Academic and Scientific communities

43 of 91

Recruiting the next gen of civic technologists

44 of 91

Recruiting the next gen of civic technologists

45 of 91

46 of 91

GraphQL API

5

47 of 91

Playing by the Rules

City of Austin Digital Service Values

Value #3: Cultivate Digital Community�“Open solutions to comments and code from interested citizens. Encourage collaborative research, design, and development through active community engagement.”��Value #6: Support agile procurement strategies that avoid vendor lock-in�“Default to open source.”

The USDS Digital Service Playbook

Play #8: Use modern technology�“...digital services teams should consider using open source, cloud-based, and commodity solutions across the technology stack…”

Play #13: Default to open�“When we collaborate in the open and publish our data publicly, we can improve Government together.”

Cultivate Digital Community

No Lock-In, Default to Open

48 of 91

Types of APIs

_SOAP_

_REST_

_GraphQL_

49 of 91

Can I get a metaphor?

50 of 91

Types of APIs

_SOAP_

_REST_

_GraphQL_

So you want amount of data returned, number of requests for unrelated data, and documentation as a metaphor? Let’s pretend our friend is an API and they’re gonna help us get a sandwich.

SOAP: So you roll over to SOAP like, “can you hook me up with a snack? Maybe a sandwich or some fruit if you’ve got it.” You’re buddy is like “I got just what you need.” They show you this dumpster full of food items and tells you to make your own. You definitely don’t need that amount of “food.” You’ll obviously still need to run to the store to get other ingredients. There’s probably some recipes in there to help you out, but it’s probably not worth the effort. Needless to say you stop talking to this friend.

[Too much data returned, takes several requests to fetch unrelated data, docs are there but aren’t usually very useful]

REST: Next up you try your old friend REST. They’re like “alright buddy, I’ve got you covered here.” They show you this great meal with turkey, stuffing, potatoes, gravy, sweet potatoes that you don’t want because they’re gross and probably some jello. “I just want a sandwich,” you complain. “EAT THE FOOD!” your friend bellows. You still need to make trips to the store to get something to drink and there aren’t any silverware. Requires a lot of research and manual work to determine ingredients and nutrition so you’ll just skip that part.

[Too much data returned & you only get exactly what the API provides, takes multiple request to fetch data, a lot of effort goes into making docs & usually aren’t available]

GraphQL: You can order exactly what you want. You can get a salad and a sandwich in the same trip. Even add a cookie if you want. Has ingredients and nutrition information right there to read.

[Client can choose which data is returned including related data, can query unrelated data in single request, helpful docs are generated automatically]

51 of 91

On the Shoulders of Giants

52 of 91

53 of 91

floods.austintexas.io

54 of 91

55 of 91

56 of 91

Static Site Generators

6

57 of 91

Static Site Generator

vs.

Dynamic/Server Rendered

A category of tools that the creates web pages as static files (HTML, CSS and Javascript) when the content is edited.
This is in contrast to the traditional CMS pattern that creates the web pages dynamically on a server as they are requested.
Important for sites where scale and security are paramount.

58 of 91

Technology trends and content management

Benefits of a Decoupled CMS

Scaling is cheap with static assets
Security exposure decreased
Reuse content in different contexts

websites vs mobile apps

Integration with external APIs

[Link to Jacob’s Medium Article]

59 of 91

60 of 91

austinconventioncenter.com

61 of 91

permittingatx.com

62 of 91

grackle.austintexas.io

63 of 91

React & Reusable Components

7

64 of 91

Resident-facing site & the React ecosystem

React is replacing jQuery as the most common starting place front-end javascript.
Component architecture has great potential for reuse across projects.
Already using React with floods.austintexas.io.
Strong ecosystem and growing.

65 of 91

Separation of Concerns

20th Century “The Olden Days”

21st Century “The Component Age”

Javascript

HTML

CSS

Header

Posts

Details

Footer

66 of 91

React Static vs Server Rendered React

React Static is a progressive static-site framework for React
Built to optimize for SEO, site performance, and user/developer experience
Site first loads bare minimum of assets, then progressively adds minimized React bundle for interactivity
Con: Build speed & targeted diff strategy

67 of 91

Storybook

Storybook is a development environment for UI components.
It allows you to browse a component library, view the different states of each component, and interactively develop and test components.
It helps us prevent our components from being too tightly coupled to any specific CMS logic.
It’s also good for onboarding and for our designers to have our component library documented this way.

alpha.austin.gov/storybook/

68 of 91

69 of 91

Devops & Containers

8

70 of 91

Playing by the Rules

The USDS Digital Service Playbook

Play #9: Deploy in a flexible hosting environment�“Our services should be deployed on flexible infrastructure, where resources can be provisioned in real-time to meet spikes in traffic and user demand.”

Play #10: Automate testing & deployments�“Perform deployments automatically with deployment scripts, continuous delivery services, or similar techniques.”

City of Austin Digital Service Values

Value #2: Teams + Skills�“Identify opportunities for city-wide standards.”��Value #3: Cultivate Digital Community�“Empower employees to discover and cultivate new skillsets that align with organizational goals.”

Teams + Skills

Cultivate Digital Community

71 of 91

What is a Container?

72 of 91

Drawing an Owl

_Local_

_Test_

_Deploy_

73 of 91

Drawing an Owl...with Containers

_Local_

_Test_

_Deploy_

74 of 91

Wagtail CMS Dockerfile

FROM python:3.6.4-slim-stretch

COPY /deploy/requirements.txt /deploy/requirements.txt

RUN pip install --no-cache-dir -r /deploy/requirements.txt

ENV PORT ${PORT:-80}

EXPOSE $PORT

RUN mkdir /app

WORKDIR /app

COPY "$PWD/docker-entrypoint.sh" /app/docker-entrypoint.sh

COPY "$PWD/joplin" /app/joplin

ENTRYPOINT ["./docker-entrypoint.sh"]

CMD ["gunicorn", "joplin.wsgi:application", "--pythonpath", "/app/joplin"]

75 of 91

76 of 91

77 of 91

We use containers for deployment

because they help us achieve our goals of being flexible and automated

78 of 91

Working in the Open

9

79 of 91

80 of 91

Test

81 of 91

82 of 91

83 of 91

Build living digital services that grow, adapt, and improve with user needs.

84 of 91

We need your help

10

85 of 91

Changing up Local Government

86 of 91

Human-Centered Design + Agile Software Development

87 of 91

odd.austintexas.io

88 of 91

89 of 91

90 of 91

91 of 91

Thanks!

mateo .clarke@austintexas.gov

bit.ly/open-city-cms

Learn more about the

Office of Design & Delivery at:

odd.austintexas.io

@civi queso