Architecture and Implementation Overview
Two Services
The Ontology Manager is made of two servers/services:
- A Postgres Database
- A web backend made of:
- A Nuxt app, using Apollo as GraphQL client
- A Nuxt Server Middleware that is trifid-core, see trifid
- A Nuxt Server Middleware implemented as an Express API
- This is where the forge-specific functionality (GitHub, GitLab, …) is implemented
- Configurable via
nuxt.config.js
- A Nuxt Server Middleware serving a GraphQL API backed by Postgres, schema generated by introspecting the pg schema
Trifid
The Trifid middleware is used to allow ontology content dereferencing, meaning that if http://your.editor.com/schema/SomeObject
is an IRI in your ontology, you will be able to get N-Triples via content negotiation: curl http://your.editor.com/schema/SomeObject -H 'Accept: application/n-triples'
.
Database Objects
Proposals
thread.headline
: the PR title and proposal title used in proposals lists- Sample value:
Change property 'wheelCount'
- Sample value:
thread.iri
: the IRI of the object from which the proposal originated- Sample value:
http://example.com/schema/wheelCount
- Sample value:
thread.body
: the motivation for this proposal- Sample value:
wheelCount currently has no type although it should be an integer
- Sample value:
thread.thread_type
:- Value:
proposal
- Value:
thread.status
: a new proposal is alwaysopen
, admins can then set it to one of:resolved
,rejected
,hidden
- Sample value:
open
- Sample value:
thread.is_draft
:TRUE
until the proposal author submits their proposal- Sample value:
FALSE
- Sample value:
thread.proposal_object
: the actual proposal content in a serialized format, cf.proposalSerializer
andproposalDeserializer
thread.branch_name
:- Sample value:
2019-03-12T140521.151Z
- Sample value:
Proposals are handled by one of these two store modules depending on their type:
These store modules are responsible for loading a proposal from the DB, saving a proposal to the DB, etc.
Threads
- A thread can either be a
discussion
or aproposal
. - A thread with
discussion
type is a conversation, messages belong to a thread.
Extending the Ontology Manager
Forges
The only forge supported at the moment is GitHub. Implementing other forges was planned from the get-go so the project is not tightly coupled with GitHub.
Whenever the manager needs to interact with GitHub, the frontend hits the API which then deals with the GitHub API. (This strategy also prevents leaking the credentials used to connect to the forge.)
./api/
contains two forge implementations:
github
, used in the demoe2e-test
, a dummy implementation used by the end-to-end tests
A new backend API could be started by copying the github API and adapting the implementation of each endpoint to the new forge.
Depending on the manager configuration, the manager loads the appropriate backend.
There are a few places where this separation of forge implementations bleeds into other files, namely all the startup config things: the new forge should be detectable in nuxt config, the “env migrator” responsible for loading env variables config into the database config table, and the dummy config loaded by default.