Gothic

The successor to Ghost and Lapiz.

Gothic runs in Go on a dedicated server. It is not meant to run behind Apache or share the machine with other services. But it can make efficient use of very small machines and scale out to utilize additional nodes efficiently.

Components

• Blueprints: schemas, data designs
• Mason: server level compiler
• Carpenters: UI (JS,CSS,HTML) compiler
• Arch: UI runtime
• Vault: Persistance
• Portal: API/transport
• Spire: UI
• Lancet: Core(server) framework

Blueprints

Gothic is built around blueprints. A blueprint is like a model or schema. It defines a set of data and it's relationships.

Blueprints also define special modifies for:

• UI
• Storage
  • non-persistant fields
  • manually defined indexes
  • auto-indexing
• API
• Validation

All instances are entities. They have an id field, a guid.

Arch

This is the hard bit. How to take the blueprints and translate them to something powerful, mostly automated, but still flexible.

I think it will use 2 Web Workers + the main window by default. One worker will handle any processing, the other will handle networking. If the models are all encoded as ArrayBuffers, they can be passed around easily. I can also translate their code to Asm.js. But this means they cannot interact in Asm.js.

Vault

I'm torn on this. I may use a no-sql (I think mongo). But I may be able to handle this in Go very efficiently.

Why do it in Go? Store the data as Gobs. I can store data in a memory cache. I can watch memory usage and when it get too high, start removing cached items, or dropping indexes to disk. I can also watch for what indexes are most used, least used and what indexes would help with queries.

Though Experiments

• Basic relay chat server
• Wiki
• Work logs