Skip to content

Instantly share code, notes, and snippets.

@Em-AK
Last active April 28, 2017 11:20
Show Gist options
  • Save Em-AK/c9e869a055ad1808562f6bef69afe06a to your computer and use it in GitHub Desktop.
Save Em-AK/c9e869a055ad1808562f6bef69afe06a to your computer and use it in GitHub Desktop.
Architecture brainstorm : Static site generators x Decentralization (via LDP)

Schema legend:

  • in blue = the components
  • in black = who owns what?

Components

  • Wordpress server with wpldp
    • as a backoffice
    • as a JSON-LD API
  • JS client(s) requesting the data API on each page load
    • the client code knows what are the data sources to request

current

Pros

  • good separation of data management and client code

Cons

  • Poor client performance, due to lot of HTTP calls to the JSON-LD API at each visit
  • If wordpress suffers, breaks or get hacked : the website is down

current under stress

Components

  • Wordpress server with wpldp
    • as a backoffice
    • as a JSON-LD API
  • Git repo to version the source code of the client (templates + images + CSS + maybe JS components)
  • Builder (Gitlab CI runner, AWS Lambda or OpenWhisk function, ...) to build the website by injecting the data into the templates and then push the static files to the Web server. The build can be triggered by:
    • a new commit in the git repo
    • a data update in any of the data source tracked by the website
      • the builder code knows what are the data sources to keep an eye on
  • Web server (CDN or static file server) to serve HTML and assets to the browser
  • [Optionnal] Ajax code that can still directly request the data source(s) for fancy features difficult to achieve in full static mode

future

Pros

  • good separation of data management and client code

  • easier to scale in case of high traffic (only the webserver has to scale)

  • renders faster in the browser (no ajax calls to wait for)

  • a bit more fault tolerant from the visitor point of view, the website is down only when the webserver is future_under_stress

Cons

  • more components to coordinate (devops to the rescue!)

Pain points

Mechanism to trigger a build on any data source update

How to achieve that ?

Constraint: a wordpress server can not be aware of who are the clients (here the builders) that consume its data (open bar decentralization hey!). So the server can not POST a message (webhook) to trigger a list of specific builders. In the other hand the git server can do that because there is a 1-to-1 relationship between a git repo and a website.

Ideas

  • Polling: the Builder periodically query each of its data sources and trigger a build if the data changed
  • Publish/Subscribe: Wordpress publish a message in a channel on each data update, any external Builder can subscribe to this channel and trigger a build when a message is published

Keep in mind

Static = build on each update (of data or source code)

VS

Dynamic = build on each page request

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment