You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/architecture.md
+2
Original file line number
Diff line number
Diff line change
@@ -8,6 +8,8 @@ description: Jekyll Admin exists in two parts, a Ruby back end and a Javascript
8
8
9
9
Jekyll Admin piggybacks on Jekyll's built-in Webrick server. We monkey patch the `jekyll serve` command to hook in two Sinatra servers, one to serve the static front end that lives in `lib/jekyll-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 Jekyll server (and we rely on third-party plugins like `sintra-json` and `sinatra-cross_origin`).
10
10
11
+
**Note:** Since there are two Sinatra servers that might call `site.process` concurrently, Jekyll Admin disables `--watch` and `--detach` flags 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 Jekyll Admin runs.
12
+
11
13
## How Jekyll Admin formats Jekyll objects for the API
12
14
13
15
Whenever possible, we want to stay as close to the `to_liquid.to_json` representation of Jekyll'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 `JekyllAdmin::APIable` module, which gets included in native Jekyll objects like Pages and Documents to add a `to_api` method which we can call to generate hashes for use in the API.
0 commit comments