Skip to main content

Overview

  • Clients send queries to nodes in order to publish new entries and query materialised documents
  • Queries are sent via HTTP using the GraphQL language
  • Serving a GraphQL API and handling requests is implemented in nodes, for example Aquadoggo
  • Nodes use the same GraphQL API to talk to each other, you can read more about it under replication
  • Large numbers are encoded as strings in the payloads (logId and seqNum) to account for the lack of support to represent u64 integers in JSON

Client API (publishing & queries)

  • The client api is the interface for communication between node and client
  • Clients can publish entries
    • Before that, clients can retrieve parameters required for encoding entries if they can't compute them independently
  • Clients can retrieve materialised documents of a given schema
    • Documents can be filtered by individual fields
    • Linked documents can be retrieved
    • Documents can be sorted by arbitrary fields
    • Documents can be sorted by self-referential orderings
    • Documents can be queried by document_view_id in order to receive a [documents][view] onto its data at a specific materialised state

Replication API

  • This api consists of GraphQL queries for other nodes to ask about the state of Bamboo logs, entries and payloads
    • These queries are enough to build a flexible replication protocol on top
  • Nodes need to implement the API specifications to make sure they are compatible with all other node and client implementations. The Node API is specified here, the Client API is further specified under [queries][queries], both APIs reside inside nodes