Dgraph (Cloud) for user-defined custom schemas?

Users Dgraph Cloud
1

Can someone smarter than me help me understand how Dgraph (Cloud) might be configured to allow multiple users/customers the ability to define their own data schemas.

The equivalent in relational db’s of allowing non-technical users the ability to create custom tables and/or fields. In the relational db world this might be achieved either directly as direct table schema changes (such as the Strapi CMS does) or via the Entity Attribute Value multi-table approach?

Customer 123 could, perhaps, create their own data collection schema, the equivalent of:

type Book {
   title: String
   price: Int
   author: Author
}

type Author {
   name: String
   books: [Book]
}

And query it etc.

Unlike the mess in a relational database, the “Entity Attribute Value” triples are built into how graph db’s organize data, yes? And Dgraph stores everything as generic nodes and edges yes, and so those “book”, “title”, “price”, “author” etc labels could be anything easily user defined yes?

But it’s still not clear to me how that might work or how the schema/structure of those nodes and edges (such as the books, author above) would be defined by a user?

And not clear to me if something like this “multiple-cutom-schemas” is a maintainable/right approach?

Or is Dgraph Cloud simply the wrong tool for a job like this?

Thanks.

1 Like
2

Or might something like this be recommended?

type Collection {
   id: ID!
   fields: [Field]
   owner: User!
}

enum DataType {
   string
   integer
   float
   boolean
}

type Field {
   id: ID!
   dataType:  DataType!
   valuesString: [FieldValueString]
   valuesInt: [FieldValueInt]
   ... etc
   collection: Collection!
   owner: User!
}

type FieldValueString {
   id: ID!
   value: String
   field: Field!
   owner: User!
}

type FieldValueInt {
   id: ID!
   value: Int
   field: Field!
   owner: User!
}

etc

?

3

And I guess you would also need an instance of that collection, ie type CollectionItem?

type Collection {
   id: ID!
   fields: [Field]
   items: [CollectionItem]
   owner: User!
}

enum DataType {
   string
   integer
   float
   boolean
}

type Field {
   id: ID!
   dataType:  DataType!
   valuesString: [FieldValueString]
   valuesInt: [FieldValueInt]
   ... etc
   collection: Collection!
   owner: User!
}

type CollectionItem {
   id: ID!
   collection: [Collection!]
   stringFields: [FieldValueString]
   intFields: [FieldValueInt ]
   ... etc
   owner: User!
}

type FieldValueString {
   id: ID!
   value: String
   field: Field!
   item: CollectionItem
   owner: User!
}

type FieldValueInt {
   id: ID!
   value: Int
   field: Field!
   item: CollectionItem
   owner: User!
}

etc
4

are you using Dgraph Cloud Dedicated or shared? If you are using Dedicated, I think you might have access to use the namespace feature, Reach out to support to ask them this question.

If you are using Shared/Free, then you have to roll this yourself and it will be complicated to keep straight.

5

Thanks @amaster507 I am currently using Shared… but, yes, I now see that Dgraph has multi-tenancy via the Dedicated plan.

And so:

  • I would use one tenant and its schema for all common functionality of my service
  • I see docs on how an admin might manually (via Cloud GUI) add a new tenant/customer where someone could define namespaces, ACL groups and data schemas… but to do this programmatically, I’m assuming, I would use admin GraphQL mutation to:
    – Create new namespace via addNamespace
    – Create ACL group via addGroup
    – Create admin user for that namespace and group via addUser
    – (Is this documented anywhere for programmatic multi-tenancy tenant creation?)
  • And then my software would allow them:
    – To login and access/edit only their namedspaced data via a Dgraph client that offers loginIntoNamespace()?
    – And to edit their schema via admin GraphQl mutation updateGQLSchema (there is no way to update schema using the GraphQL schema notation approach I take it?)
6

umm, you answered your own question and then contradicted it. You update the GraphQL schema using the updateGQLSchema mutation, yes.

each namespace should have their own dedicated GraphQL endpoint. I am not sure how that looks at the namespace version of Dgraph, I just know it is possible, because it is exactly how Dgraph servers Dgraph Cloud Shared instances. Basically you are trying to rebuild some of Dgraph Cloud where you become the host of the clients almost in a reseller like fashion.

7

Ha. Really? How so?

Well, allowing customers to create custom data models (via GUIs, not config files) may be similar, yes, but I’m not trying to create a Dgraph Cloud BaaS backend-as-a-service primarily for developers (who go on to create their own views and business logic etc via separate code to view and manage that data.)

My goal is an opinionated, niche-focused SaaS primarily for non-technical business users where the bulk of end-user interactions happens within my SaaS interface and its opinionated views and within its business logic (not via customers’ custom code hosted somewhere), but that, yes, accesses/manages the customers’ user-created custom data.

Think Airtable, highly configurable project management tools or other niche SaaS tools for mostly non-technical users that provide opinionated views and business logic, team collaboration and other features along with, yes, the management of the customer’s custom-schema data.

Example: SaaS app that customers use would use GraphQL mutations behind the scenes to access their team’s data, mutate that data, manage their team users and even modify their data schema (for the parts of the service that allow custom data schemas.)

If I’m not mistaken, the process I laid out above might serve that purpose, yeah? Or perhaps I’m mistaken?

Thanks much @amaster507 !