mirror of
https://github.com/TryGhost/Ghost.git
synced 2024-11-30 21:40:39 +03:00
bbcc0f5178
no issue - New Member API batched import is meant to be a substitution to current import with improved performance while keeping same behaviore. Current import processes 1 record at a time using internal API calls and times out consistently when large number of members has to be imported (~10k records without Stripe). - New import's aim is to improve performance and process >50K records without timing out both with and without Stripe connected members - Batched import can be conceptually devided into 3 stages which have their own ways to improve performance: 1. labels - can be at current performance as number of labels is usually small, but could also be improved through batching 2. member records + member<->labels relations - these could be performed as batched inserts into the database 3. Stripe connections - most challanging bottleneck to solve because API request are slow by it's nature and have to deal with rate limits of Stripe's API itself - It's a heavy WIP, with lots of known pitfalls which are marked with TODOs. Will be solved iteratively through time untill the method can be declared stable - The new batched import method will be hidden behind 'enableDeveloperExperiments' flag to allow early testing |
||
---|---|---|
.. | ||
canary | ||
shared | ||
v2 | ||
index.js | ||
README.md |
API Versioning
Ghost supports multiple API versions. Each version lives in a separate folder e.g. api/v2, api/v3, api/canary etc. Next to the API folders there is a shared folder, which contains shared code, which all API versions use.
Stages
Each request goes through the following stages:
- input validation
- input serialisation
- permissions
- query
- output serialisation
The framework we are building pipes a request through these stages in respect of the API controller configuration.
Frame
Is a class, which holds all the information for request processing. We pass this instance by reference. Each function can modify the original instance. No need to return the class instance.
Structure
{
original: Object,
options: Object,
data: Object,
user: Object,
file: Object,
files: Array
}
Example
{
original: {
include: 'tags'
},
options: {
withRelated: ['tags']
},
data: {
posts: []
}
}
API Controller
A controller is no longer just a function, it's a set of configurations.
Structure
edit: function || object
edit: {
headers: object,
options: Array,
data: Array,
validation: object | function,
permissions: boolean | object | function,
query: function
}
Examples
edit: {
headers: {
cacheInvalidate: true
},
// Allowed url/query params
options: ['include']
// Url/query param validation configuration
validation: {
options: {
include: {
required: true,
values: ['tags']
}
}
},
permissions: true,
// Returns a model response!
query(frame) {
return models.Post.edit(frame.data, frame.options);
}
}
read: {
// Allowed url/query params, which will be remembered inside `frame.data`
// This is helpful for READ requests e.g. `model.findOne(frame.data, frame.options)`.
// Our model layer requires sending the where clauses as first parameter.
data: ['slug']
validation: {
data: {
slug: {
values: ['eins']
}
}
},
permissions: true,
query(frame) {
return models.Post.findOne(frame.data, frame.options);
}
}
edit: {
validation() {
// custom validation, skip framework
},
permissions: {
unsafeAttrs: ['author']
},
query(frame) {
return models.Post.edit(frame.data, frame.options);
}
}