Export schema

[neumino]

We can just implement a method toJSON on each type.

[freak4pc]

+1

[kheide]

How is it going with this? I looked at implementing the toPublic define function you mentioned in another issue, but when I am returning an array of results I don't want to iterate over it, add this function and then return it.

[neumino]

@kheide -- I'm not sure to understand your question. What don't you want to do?

[nook-scheel]

+1

[tlvenn]

+1

Would be interesting to facilitate adoption of GraphQL with Thinky.

[neumino]

Exporting a schema is technically not too hard. What's harder is to reimport it. Then while I opened this issue, I'm a bit fuzzy on why people would need that and what they would do with that:

• What's the expected output for the schema? How to report properties like min, max etc.
• Should it be JSON?
• Should it include relations?

[tlvenn]

One use case is to interface it with GraphQL for example. GraphQL expects your to build a schema for your app and if you use Thinky, that schema gonna be pretty close to the one you already have declared in Thinky.

Using a fluent GraphQL builder like https://github.com/devknoll/graphql-schema, one could leverage the schema from Thinky to build most of the schema needed for GraphQL.

Graffiti is for example a project which aims to do that and they have an adaptor for Mongo: https://github.com/RisingStack/graffiti-mongoose

It would also be pretty cool to be able to attach some meta on attributes and relations that such tool could leverage. By that I mean, let users attach any meta whatsoever.

As far as GraphQL is concerned, for each attributes, it needs its type, if there is a not null constraint and if there is a default value. I would imagine that for reflection purpose that might be enough also. Not sure either how to best export complex validation rules.

99% of the time, you would want to consume directly such schema in JS, so JS objects would make more sense.

And yes, relations are a must.

There is absolutely no need imho to support the reverse process of re importing a schema export which definitely would be much harder.

[ghost]

+1 for anything that helps support gaphql

[neumino]

Can someone actually write down what exporting a schema means? I can add a type field and then just call JSON.stringify on it, but I'm pretty sure this is not what people want.

Also I'm not sure to understand what the point of GraphQL. It's a query language, but I don't see how this help to query RethinkDB. There's an issue to support it, but this is not settle yet. Or maybe I'm missing something about GraphQL?

[grantcarthew]

I have another use case for you Michel. I am doing full stack dev on a webapp and the front end is using Aurelia for SPA.

To manage the data in the front-end I am creating models for the client to hold state and apply business logic. I would love to be able to export the models from the server through the server API to keep with DRY.

So an example of this would be when a new resource is created in the client, lets say a new product item, rather than making a JSON object on the client with all the properties that are required fields manually, it would be nice to query the server API and get a skeleton product object straight from the Thinky model.

I am no expert and maybe there is a better way to do this, however being able to export the models would be handy.

[tlvenn]

Hi @neumino,

GraphQL has an ambiguous name somewhat and is not a query language as you expect but more a Type system for your application that provides introspection, validation and execution.

To get a better understanding of GraphQL, please have a look at those 2 videos:

https://www.youtube.com/watch?v=WQLzZf34FJ8 https://www.youtube.com/watch?v=gY48GW87Feo

I also feel obligated to recommend the awesome video of Lee Byron on Immutability that I believe you will appreciate ;)

https://www.youtube.com/watch?v=I7IdS-PbEgI

As @grantcarthew pointed out, the same kind of use case happen if you are working on a SPA without GraphQL. Let's say Aurelia as in his example and you use js-data to manage well, your data (Same story with Ember-data). Then you will have to create a schema to let js-data know the shape and relationship of your data.

Pretty much what you did already with Thinky.

[neumino]

I watched the talks, but that doesn't really tell me what the output of the export should be. It seems pretty different to support GraphQL or be able to export the full schema.

Typically how each of these options would be rendered? Do we even return these options or the type?

[yocontra]

FWIW I wrote code for this:

import mapValues from 'lodash.mapvalues'

const exportSchema = (schema) =>
  mapValues(schema, (v, k) => {
    if (v._schema) {
      return exportSchema(v._schema)
    } else {
      return v.constructor.name.replace(/^Type/, '')
    }
  })

export default (model) => exportSchema(model._schema._schema)

Doesn't support relationships yet, when it does I'm going to release this as a module

[yocontra]

^ and published as a module if anyone wants to use it: https://github.com/contra/thinky-export-schema

[grantcarthew]

Hi @contra, this looks good. @neumino can you comment on it please? I would love your expert opinion be it good or bad.

[neumino]

Looks good to me. But I guess it mostly depends on what you need the schema for.

[grantcarthew]

Thanks for that. I was looking for a way to get the models into my single page app from the back end. I think this may do the trick. @contra @neumino