Below is a list of technical decisions to make before GA.
*_every filters
Graphql server provides *_every filters:
query {
# select users who have only high profile friends
users(where: {friends_every: {rating_gt: 100}}) {
id
name
}
}The question is what to do when user doesn't have friends.
Include user in result set
Pros:
- In all programming languages
[].every(() => false) == true
- The opposite behaviour is easy to achieve with
where: {friends_every: {rating_gt: 100}, {friends_some: {}}}
- Openreader (hydra v5) already behaves like this.
Cons:
- Many people find such behaviour confusing
- Hydra v4 behaves in opposite way
Do not include user in result set
Pros:
- See cons of the opposite decision
Cons:
- Will be implemented as a combination of "classical every" and "some" check
- The opposite behaviour is a bit hard to achieve (
where: {_or: [{friends_every: {rating_gt: 100}}, {friends_none: {}}]})
From pure convenience point of view, v4 behaviour will probably be more frequently desired, but that's not entirely clear.
For example, the above query will most likely benefit from v4, but the query below from v5
query {
# find all accounts which where never involved in significant money transfers
accounts(where: {transfers_every: {balance_lt: 10}}) {
id
}
}Name prefixes for standard metrics
Processor runs prometheus endpoint and exposes a number of metrics including standard node_* set.
In hydra all standard metrics had hydra_processor_ prefix, but now they are exposed as is.
Someone familiar with prometheus should tell which way is better.
UPD: After reading a bit of prometheus docs, it seems, that prefix-less metrics is the way to go.
Id-less entities
For some tables you never want to reference individual raws. For such cases you don't want to bother with id assignment and allocate extra useless column in database, yet our framework requires explicit id assignment for all entities.
Currently it is possible in schema.graphql to omit id field in entity type, but framework will still create it implicitly.
We can change the behaviour and create id-less tables in such cases.
If we accept the above idea, the next question will be about necessity of composite primary keys for such tables.
We are planning to support multi-field indexes via entity level index annotations:
type Foo @entity @index(columns: ["foo", "bar"]) {
foo: Int!
bar: Int!
}Primary key could be specified like this:
type Foo @entity @index(columns: ["foo", "bar"], unique: true) {
foo: Int!
bar: Int!
}From database point of view primary keys are not required and it would be convenient to create primary-key-less tables for id-less entities, however TypeORM requires primary key.
We can do something like this:
@Entity()
export class Rec {
constructor(props?: Partial<Rec>) {
Object.assign(this, props)
}
@PrimaryGeneratedColumn('rowid')
private _id!: number
@Column()
x!: number
@Column()
y!: number
}but this will still expose non-deterministic column on a database level, which is not ideal for applications which connect to database directly.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent