The current 'query language' conflates queries with the type system and is difficult to read due to field names (as mutator/modifier) being at the bottom. This could be simplified by using a json tree and leveraging the type system. Thought I would give a proper example after our discussion earlier.

current implementation

import { query } from 'modelizr'
import { event, organization, user, book } from './schema.js'

query(
    event(
        organization(
            user(
                book(
                    user(
                        company(
                            user().as('father')
                        ).as('employer')
                    ).as('author'),
                    book(
                        user(
                            user(
                                user().as('mother')
                            ).as('guardian')
                        ).as('author'),
                    ).as('inspiredBy')
                ).as('favoriteBook')
            ).as('founder')
        ).as('company')
    )
)

proposal

import { query } from 'modelizr'
import { event } from './schema.js'

query(
    event({
        company: {
            founder: {
                favoriteBook: {
                    author: {
                        employer: {
                            father: {}
                        }
                    },
                    inspiredBy: {
                        author: {
                            guardian: {
                                mother: {}
                            }
                        }
                    }
                }
            }
        }
    })
)

and alternatively for the adventurous

import { query } from 'modelizr'
import { event } from './schema.js'

query(
    event({
        company: {
            founder: {
                favoriteBook: {
                    author: {
                        employer: {
                            father: {}}},
                    inspiredBy: {
                        author: {
                            guardian: {
                                mother: {}}}}}}}})
)

Hi Julien,

I think the idea of modelizr is great! :)

Do you have any feedback after one year?

The Problem

The current implementation of models aren't flexible enough for use in real world applications. As soon as queries require models with different keys, things start to feel hacky and, well, wrong. Take for example the following case:

import { model, query } from 'modelizr'

const user = model('users', { ... })

query(
   user()
)

This makes sense and is easy to use, however things can quickly become messy:

query(
   user(
      book(
         user().as('author')
      )
   ).as('user'),

   book().as('book')
)

Introducing the alias() util and proposal #2 helped clean this up a bit to look like this:

const author = alias(user)

query(
   user('user',
      book(
         author()
      )
   ),

   book('book')
)

However this still feels wrong to me.

As a side effect, specifying whether or not a top level models in a query should be mocked as a collection of or single entity is hard to do. The current implementation is to pass in the models primary key as a parameter, but this won't be possible if querying a type that takes no parameters and returns a singular entity.

Some Alternatives

Here are some alternatives that have crossed my mind. I will add more as I think of them.

Allowing models to infer child model keys

When creating models, part of the process is defining their relationships with other models

user.define({
   textbooks: [book]
})

book.define(
   author: user
)

We could use these definitions to infer what the key should be inside a query

query(
   user(
      book()
   ),

   book(
      user()
   )
)

/*
{
  users {
    ...,
    textbooks {
      ...
    }
  },

  books {
    ...,
    author {
      ...
    }
  }
}
*/

This is already a lot cleaner, but there are some problems.

1. Model definitions with two relationships using the same model will not be inferable
2. Doesn't work on top level models
3. Doesn't solve the problem of single entity mocking for top level models.

Adding a define modifier to our query tools would make this option more viable

query(
   user(
      book()
   ),

   book(
      user()
   )
).define({
  user: user,
  textbooks: arrayOf(book)
})

This will solve problems 2 and 3, albeit messily, but not problem 1.

Create singular and collection models separately

When creating a model, specify the entity key and query key separately. Define collection models by aliasing singular models and wrapping them with arrayOf or valuesOf.

import { model, alias, arrayOf } from 'modelizr'

const user = model('user', 'users', { ... })
const users = arrayOf(alias(user, 'users'))

Although we would still need to use .as in our queries, it would be much clearer as to what is going on, and this would solve the mocks problem

query(
   users(
       book(
           user('author')
       )
   ),

   user()
)

or

const author = alias(user, 'author')

query(
   users(
       book(
           author()
       )
   ),

   user()
)

Much more readable! But it still doesn't feel flexible to me. It's almost as if the confusion that was queries has just moved over to the model creation process.

Input

I hope to get some feedback from other people using or interested in modelizr.

I noticed that the current implementation assumes root level queries query and mutation (I think?). Please note that while this probably how most people are using graphql, modeller shouldn't make any assumptions about user top level queries.

A top level query can have the following example forms (Again, I'm pretty sure this is how it works):

query Alias {}
someThing Thingie {}
mutation lol {}

Users should be able to specify the top level exposed name and the specific query alias. Also, mutations are functionally equivalent to queries. The only difference is convention.

const buildParameters = (params: ?Object): string => {
	params = _.pickBy(params || {}, value => value !== null && value !== undefined && !Object.is(value, NaN))
	if (_.isEmpty(params)) return ""
	return `(${_.map(_.pickBy(params, param => param || param === false), (param, key) =>
		`${key}: ${JSON.stringify(param).replace(/"([^(")"]+)":/g, "$1:")}`)})`
}

May I ask what is the purpose of _.pickBy(params, param => param || param === false ? This part of code would omit my param if my param is like {page:0}. It makes problem as my pagination 0 based. May I ask if this is on purpose? Thank you.

When defining a property type as a model:

const user = model('users')
const book = model('books', {
    author: {type: user}
})

There is no support for union, arrayOf or valuesOf

Could be interesting to explore generating modelizr code via graphql introspection.

Hi there,

I think your approach is very interesting and it would be great to see it in action in a simple example with next.js which is also a very minimal approach to react apps.

As an example here's the one for apollo

It would also give more visibility to your work!

Cheers,

Jun

Modelizr is a large bundle which is a problem when building for production. There needs to be a way to reduce this bundle size.

json-schema-faker already allows faker and chance exclusion by requiring json-schema-faker/lib. This just needs to be handled in modelizr.

Using multiple root models of the same type in a query, like this:

query(
    book(),
    book()
)

or

query(
    user(
        book()
    ),

    book(
        user().as("author")
    )
)

Will cause entities with conflicting ids to be generated. This is as the mocking cache is not scoped at a query level, but at a root model level.

The cache needs to be scoped to the query.

It would be great if you didn't have to recreate your entire graphql schema to follow Modelizr's syntax. If there was some way to hook modelizr into the existing graphql schema, it would make this library much more user-friendly.

hey this is a cool library, i'm starting to think about the same thing.

I was wondering if you thought about using normalizr going the other way for mutations. Something like this:

mutation:

user.create({
  name: 'matt',
  notes: [
    {
      id: 123,
      title: 'blah',
      body: 'hi'
    }
  ]
})

normalized:

entities: {
  users: [
    {
    name: 'matt',
    notes: [1]
    }
  ],
  notes: [
    {
      id: 123,
      title: 'blah',
      body: 'hi'
    }
  ]
}

database inserts:

INSERT INTO users VALUES (...)
INSERT INTO notes VALUES (...)

any downsides you foresee with this approach?

Is the normalize function available globally?
What if I need to normalize something that is not being fetched via an API ?

It does not work when I import the normalizr package to my project and use that function with the modelizr schema