GraphQL scalar definition not supported

cruddl appears to be throwing errors on Graphql documentation syntax. If my schema has something like this:

"""
IS08601 time duration
"""
scalar Duration

Processing through cruddl reports errors like this:

[error]: uncaughtException: Project has errors:
Error: This kind of definition is not allowed. Only object and enum type definitions are allowed. at schema.graphqls:2:1

[Yogu]

Yes, custom scalars are not supported by cruddl. To implement it, we first need to decide how they can be configured by the schema author, because we can’t just use callbacks for validation (cruddl never uses callbacks for modelling). We could e.g. allow to specify a regular expression to validate scalars. What do you think?

[Yogu]

Something like regex would be a start so we could at least support scalar definitions to some degree. However, the lack of callbacks is problematic for several reasons. Validation is one. But there are others such as audit logging that could become really problematic for integration of cruddl.

I didn’t write cruddl does not use callbacks for configuration - it already does in several instances (just look at ProjectConfig, it’s full of optional callbacks). One callback is profileConsumer which gets called on each query - might go into the direction of audit logging.

I meant that modelling should not require callbacks. Maybe the goals of cruddl and your requirements are not exactly overlapping here - we use cruddl in a generic component called “Model Manager” where users can dynamically define their schema via a web interface. They can’t just implement a cruddl callback.

However, I’m ok with callbacks and extensive configuration if it’s not directly coupled to the cruddl type definitions in the ProjectSources. For example, we could make the system scalars configurable. That would be pretty simple actually - it’s just an array of GraphQLScalarType classes. We could easily make this list configurable.

it can’t be an impenetrable line between graphql and arango. Developers need to be able to inject and extract data along that pipeline.

This line is the opposite of impemetrable! Actually, that’s the part of cruddl that’s closes to a “plugin” architecture. When creating a schema, you specify a database adapter. There, you can pass custom database adapters. For example, you can create a subclass of ArangoDBAdapter (or use composition) and hook yourself into executeExt. This method gets passed something called QueryTree which is an abstract representation of the query or mutation to be executed. You can e.g. modify the query tree or do audit checks, and then pass it to the original ArangoDB Adapter.

However, the modelling features currently don’t follow a plugin architecture. In an earlier version of cruddl, we used a pipeline approach to gradually “enhance” the cruddl-input to the real, executable GraphQL schema. However, that approach got pretty messy pretty quickly, and we developed a framework that allows us to implement features in a cleaner way.