skinsmili.blogg.se - Graphql as a universal database abstraction

Graphql as a universal database abstraction how to#
Graphql as a universal database abstraction code#

Additional constraints can be defined by the developer for a specific language via configuration.įrom here on I will use the term “dialect” instead of “language”, as well as “subdialect” to mean a variation of a language.

as a set of type definitions, it can be represented in other languages, which may introduce constraints of their own.

as a conceptual model, it doesn’t get bogged down into implementation detail and therefore focuses on what is important to the domain expert (e.g., a business analyst).

Those constraints can be tightened in the chosen target language(s) of the implementation. Like GraphQL, UTS would have simplified cardinality constraints of one-to-one, one-to-many, and zero-to-many. So, a UTS schema sketches out the kinds of data used in a domain, but it is not sufficient for an implementation on its own. As such, an integer in UTS is whole number without range constraint likewise, a string is a contiguous set of characters without a fixed length. In that sense, it is a purely conceptual and nonspecific description of types used in a domain. Aspects of Universal Type SystemĪ UTS schema, which defines primitive and compound types, does not dictate an implementation. Unlike primitives, which are defined by the language, compound types are “custom” types.

The programmer defines them, gives the definition a name, and uses instances of them in code. Plain Old Data Object (PODO, various languages).

Most languages support the following:Ī compound type is defined as a container for primitive and other compound types. These correspond to data stored atomically in memory. I’m using the word “structure” in this case to refer to primitive data types and compound data types. Data of a type must conform to the definition. Primitive and compound data typesĪ type is a named data structure definition. What follows is a general outline of what such an abstraction might look like, and how it would operate. It made me wonder if the general concept can be abstracted away from specific implementation details. Off the top of my head:ĭefining data types and generating language-to-language mappings are a core part of these technologies, so this type of problem repeatedly crops up. Deja vu all over againĪny sufficiently complex computer application has dealt with converting from one set of types defined in one language to a similar set of types in another. The drawback is that directives bind the GraphQL schema to a particular language or data store.

Graphql as a universal database abstraction how to#

There is also support for directives which allows tweaks can be made to the schema to inform a language generator (or validation engine) how to map GraphQL types to other language types. These data types are used to define and validate the structure of HTTP POST calls to a server, where the POST body is JSON. GraphQL has a simple yet extensible way of defining data types in a declarative way.

Graphql as a universal database abstraction code#

Not dissimilar to how an ORM maps Java classes to SQL statements, or how Swagger-based code generators provide a framework generated from an REST API definition. Since I have worked with GraphQL quite a bit in the past I liked the idea of fleshing out a GraphQL API, which includes type definitions, and generating TypeScript functions that invoked SQL to perform underlying CRUD operations. I recently made some minor contributions to an open source project that took a GraphQL schema as its input and generated viable SQL dialects for various databases.