How Bunto Admin hooks into Bunto

Bunto Admin piggybacks on Bunto’s built-in Webrick server. We monkey patch the bunto serve command to hook in two Sinatra servers, one to serve the static front end that lives in lib/bunto-admin/public/dist via /admin, and one to serve the Ruby API via /_api. Once the Sinatra servers are mounted, they work just like any other Bunto server (and we rely on third-party plugins like sintra-json and sinatra-cross_origin).

Note: Since there are two Sinatra servers that might call site.process concurrently, Bunto Admin disables --watch flag to prevent a race condition between these servers that might cause incorrect responses for the API. This ensures that the site is regenerated by only the process that Bunto Admin runs.

How Bunto Admin formats Bunto objects for the API

Whenever possible, we want to stay as close to the to_liquid.to_json representation of Bunto’s internal object structure as possible, so that we’re (A) using data structure that developers are used to, and (B) so that we can benefit from upstream improvements. To do this, we have the BuntoAdmin::APIable module, which gets included in native Bunto objects like Pages and Documents to add a to_api method which we can call to generate hashes for use in the API.