Phony

Data

Data model

Phony builds the graphql query from your data. There are a few requirements to ensure phony can do its magic without problems.

The database should be an object with collections, where each collection is an array of objects. It is advised to keep these objects flat but phony will build types for nested objects to allow a full specification.

Collections

The first entry needs to have all properties defined. the second entry only needs the required properties. Phony looks up the first entry and uses it to build the type. If it does not appear in the second entry it is treated as an optional property.

Example

The following snippet shows a usable format. The generated schema can be seen below.

module.exports = {
users: [
{
id: 123
name: "John Doe",
email: "john@doe.com" // optional
},
{
id: 456
name: "Jane Doe",
}
]
};

This is the schema generated from the data above

type Query {
allUsers(pagination: Pagination, sorting: Sorting, filter: UsersFilter): [User]!
User(id: ID!): User
_allUsersMeta: MetaData!
}
type Mutation {
createUser(input: UserInitInput!): User!
updateUser(id: ID!, input: UserUpdateInput!): User!
removeUser(id: ID!): Boolean!
}
type User {
id: ID!
name: String!
email: String
}
type MetaData {
count: Int!
}
input Sorting {
field: String!
order: SortOrder!
}
enum SortOrder {
asc
desc
}
input Pagination {
page: Int
pageSize: Int
}
input UsersFilterFields {
id: ID
name: String
email: String
}
input UsersFilter {
q: String
fields: UsersFilterFields
}
input UserInitInput {
name: String!
email: String
}
input UserUpdateInput {
name: String
email: String
}

Phony generated dates

Phony uses the created and updated properties (names configurable) of entries. These are added when mutations write to the local database. If you want to use them you should add them to your data so they will be picked up by the query. If you don't need them they will simply be ignored.

module.exports = {
users: [
{
id: 123,
name: "John Doe",
email: "john@doe.com",
created: new Date(),
updated: new Date()
},
{
id: 456,
name: "Jane Doe",
created: new Date()
}
]
};

Available on User

type User {
name: String!
id: ID!
email: String
created: String!
updated: String
}

Relationships

Items from different collections can be linked with the _id suffix.

Example Data

module.exports = {
posts: [
{
id: 1,
title: "Lorem Ipsum",
user_id: 123
},
{
id: 2,
title: "Sic Dolor amet",
user_id: 456
}
],
users: [
{
id: 123,
name: "John Doe"
},
{
id: 456,
name: "Jane Doe"
}
],
comments: [
{
id: 987,
post_id: 1,
body: "Consectetur adipiscing elit"
},
{
id: 995,
post_id: 1,
body: "Nam molestie pellentesque dui"
}
]
};

Many to One

{
getPost(id: 1) {
title
User {
name
}
}
}
{
"data": {
"getPost": {
"title": "Lorem Ipsum",
"User": {
"name": "John Doe"
}
}
}
}

One to Many

{
getPost(id: 1) {
title
Comments {
body
}
}
}
{
"data": {
"getPost": {
"title": "Lorem Ipsum",
"Comments": [
{ "body": "Consectetur adipiscing elit" },
{ "body": "Nam molestie pellentesque dui" }
]
}
}
}

Special prop names

Phony has a few restrictions when naming properties in your entries.

Phony looks for special names to determine if a property is required or how the type should be defined.

  • [name]_id: defines a relation. This value will be used to build relations
  • __first + __second: these terms are used internally to determine if a field is required, "DON'T USE THEM in your database".
  • created: defines the creation date of the entry. If you need access please list it in the first entry of your collection. Phony will write this property when new items are added. (name configurable)
  • updated: defines the update date of the entry. If you need access please list it in the first entry of your collection. Phony will write this property when items are updated. (name configurable)