mirror of
https://github.com/bellingcat/datasheet-server.git
synced 2026-06-11 04:48:32 +03:00
update readme
This commit is contained in:
22
docs/design-concepts.md
Normal file
22
docs/design-concepts.md
Normal file
@@ -0,0 +1,22 @@
|
||||
### Design Concepts
|
||||
The codebase currently only supports Google Sheets as a source, and a REST-like format as a query language. It is designed, however, with extensibility in mind.
|
||||
|
||||
**Sources**
|
||||
A source represents a sheet-like collection of data, such as a Google Sheet. A source has one or more **tabs**, each of which contains a 2-dimensional grids of cells. Each cell contains a body of text (a string).
|
||||
|
||||
**Resources**
|
||||
The data from sources are made available as resources, which are structured blocks of data that are granularly accessible through a query language. Resources are the outfacing aspect of Datasheet Server, and represent the only kind of data that can be queried by applications. Each resource is configured with one or more **query languages**. (Currently only a REST-like query language supported.)
|
||||
|
||||
**Blueprints**
|
||||
Blueprints are a data structure that represent the way that infromation from **sources** are to be turned into **resources**. For each tab in a source, there is a corresponding Blueprint. Blueprints are created through a [blueprinter function](/src/blueprinters) invoked on the raw data from a source tab.
|
||||
|
||||
Blueprints are JSON objects. There have two forms:
|
||||
|
||||
1. _desaturated_ -- describes the resources and query languages available on data from a source tab.
|
||||
2. _saturated_ -- both describes resources available on data from a source etab, and contains that data.
|
||||
|
||||
A desaturated Blueprint can be saturated by retrieving its data from the server's **model layer**, which stores tab data from sources.
|
||||
|
||||
A JSON catalogue of the available blueprints (desaturated) in a server is available at `/api/blueprints`.
|
||||
|
||||
|
||||
19
docs/gsheet-config.md
Normal file
19
docs/gsheet-config.md
Normal file
@@ -0,0 +1,19 @@
|
||||
## [Configuration](#configuration)
|
||||
Copy the example environment file:
|
||||
```
|
||||
cp .env.example .env
|
||||
```
|
||||
Inside this file, you will need to modify at least the `SERVICE_ACCOUNT_EMAIL` and `SERVICE_ACCOUNT_PRIVATE_KEY` fields. These fields refer to the credentials of a [Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). Google requires that developers create these when attempting to access their services programmatically, so that they can attribute requests to users. Service accounts also contain identity information, which means that asset owners can allow certain service accounts access to certain sheets, just as one might differentially grant certain users access to certain cloud assets.
|
||||
|
||||
Once you have [created a service account](https://support.google.com/a/answer/7378726?hl=en), create and download an [API key for that account](https://cloud.google.com/iam/docs/creating-managing-service-account-keys). The JSON file for the API key that you download when you create it contains both a service account private key, and an email associated with the service account: add these respectively in the strings in .env for `SERVICE_ACCOUNT_PRIVATE_KEY` and `SERVICE_ACCOUNT_EMAIL`.
|
||||
|
||||
The last thing to do is to grant the service account access to the sheet that
|
||||
datasheet-server is pulling from. You can add a service account to a sheet as
|
||||
you would any other Google user: just enter the email address associated. (Note
|
||||
that this step is not necessary if you are accessing a publicly available
|
||||
sheet.)
|
||||
|
||||
Other configuration options, such as the port at which the server will expose
|
||||
resources, are also modifiable from the .env file.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user