Art, Writing & Code by Eddie Bowen

Soul of a new machine

Using a smarter schema

Eddie Bowen, Fri Oct 14 2016

OK, so we're building our dream web platform. What is the guiding principle that will inform what we're doing?

In two words, external schema.

Most web applications are essentially a UI on a database. The process is like this:

  • admin enters document in a back-end form
  • store document in database


  • fetch normalized data from the database
  • transform it into denormalized content
  • format it with a template

You push the content into the database, then sling it up when it's requested.

The usual way to do this is bespoke - if the app is SQL-based then database has a schema, but the back end has it's own understanding of the document structure; the application translates stuff into fields for the template, and so on.

Pageda is schema-driven. Every document type in Pageda is defined with a JSON schema.

Here's a typical Pageda schema:

	"name": "users",
	"extends": "base",
	"collection": "users",
	"displayAs": "Users",
	"abstract": false,
	"properties": {
		"uid": {
			"displayName": "UID",
			"datatype": "uid"
		"twitter": {
			"displayName": "Twitter",
			"datatype": "string"
		"avatar": {
			"displayName": "Avatar",
			"datatype": "image"

We're going to use the schema to drive the entire back end; the scaffolding will use the schema to lay out inputs.

This means we can set up a series of different types of posts (think of Tumblr), and the scaffolding will automatically support them.

But the main advantage of using an external schema is that it enforces consistency and prevents the app from becoming brittle. With the schema we always present the same types of data the same way.