Prose is a web-interface dedicated for managing dynamic content of Jekyll-based websites. Users of Jekyll can create, edit and delete files that live within the _posts directory. Prose can be considered a smart way of publishing for hackers and humans, solving the issue that Jekyll is has not yet been suitable for less-technical content editors.

While developers can still enjoy all freedom the Jekyll framework provides, editors can easily access, edit and publish content using a visual interface. Here is how it works:

It was challenging, but Prose supports OAuth. I think it's very important to use OAuth over Basic Authentication, since Github data can be very sensible and no one wants to risk getting his password sniffed.

This is the landing page, it gives you all the repositories you have access to. If a Jekyll site has multiple branches, you are prompted to select your desired branch, otherwise, you jump into the repo directly.

Once you have selected a repository, you can browse your posts and sub-folders in a traditional file-browser-ish manner. You can create new files here as well, which immediately opens an empty document for you, which you can save after populating it with some text.

We use CodeMirror, a great software that makes browser-based editing a pleasure (the first time). Compared to a regular textarea, which has an annoying inline scoller this is a huge step forward I think.

You can instantly preview your writing by either clicking the preview icon at the document menu bar, or use that fance keyboard combo ctrl+shift+p to toggle Preview on and off.

Once you are ready, you can easily publish your article, which lets it show up on the actual webpage/blog.

Take full control about your post, and edit Metadata aka the YAML frontmatter. No limitations.

Prose itself is just a static webpage, and doesn't require any server-side bits. Instead it interacts directly with the Github API for managing your repo's contents.

The Github API is somewhat funky from time to time, and hard to debug. We had to be aware of CORS issues and properly setting up headers for authorization. What's challenging here, is that Github just offers a low level API (around trees and blobs), which is problematic in many cases, as it requires a lot of subsequent requests to do simple things, which slows down site performance. That's why creating a good architecture was crucial to manage the complexity. I ended up in abstracting the data layer into a separate module, Github.js.

Github.js is a higher-level wrapper around the Github API. It's intended for exactly our use case, namely interacting with Github from the browser. It supports reading, writing, renaming and deleting files. Goal was to have a simple data abstraction layer, nothing to fancy, but providing exactly the operations we need.

Because of some security-related limitations, Github prevents you from implementing the OAuth Web Application Flow on a client-side only application.

This is a real bummer. So we built Gatekeeper, which is the missing piece you need in order to make OAuth work.

1. Fork and clone the repo in order to run your own instance of Prose.

2. Setup a Github application, so CORS requests are possible as well as OAuth authentication.

   

3. Setup Gatekeeper.

   Follow the instructions here and fill in the information that is provided after registering a new Github Application.

4. Adjust _config.yml.

   auto: true
   server: true
   oauth_client_id: your_oauth_client_id
   gatekeeper_url: http://gatekeeper.example.com
   exclude:
   - .gitignore
   - README.md
   

5. Run it.

   server:prose prose$ jekyll
   

The Github API comes with a number of limitations because of its low-level nature. Here is a the list of known issues related to that. I hope the folks at Github can help us (with some minor additions to their API) so we can eliminate them.

• Listing Repositories

  When listing the repositories, we can't determine which of them are actual Jekyll sites. Theoretically we could, by issuing a separate request that fetches repository information (such as branches) and looks for a _config.yml file. However this is way to slow, so we have to do it on-demand as you click on a repository.

• Organizations

  Repositories that live within your organizations can only be accessed by entering the url (/:organization/:repo/:branch) manually.

• Deleting and renaming files

  This requires a full tree to be written involving a new commit that points to that tree. In fact this is not a big problem with small repositories, but once they get bigger it's not only a performance issue, you'll get errors. Be aware that you may not (yet) be able to rename or delete files when working with bigger repositories.