Language of The Cloud

Language of The Cloud

Rabbit holes, aren't they great? I was intending to work on the type provider example set. Then I found this: a schema store with some of the biggest providers. I also noticed it backed OpenAPI, AsyncAPI, CloudEvent and a number of other providers.  This will be more of a forethought post, as I don't have a working prototype.

We are moving more and more items to the cloud and are working with different vendors, platforms, and tools. These processes introduce a number of languages that all need to talk and consume the same end data set. They also inter opt with a number of external vendors. We don't want to have to rewrite code over and over.

An example of this would be the OpenAPI specification. This allows teams to build an API via a contract. This contract can produce mock servers, which can be deployed in CI/CD or for local testing. It also allows for asynchronous development: the front-end can work on the same feature as the back-end, all while providing documentation and ease of on-boarding.

As I dug into the JSON Schema, I found a pretty well fleshed out type system with support for a majority of what most end consumer applications would require. I see several possibilities here. First is cloud provisioning and maintenance. We can build type safe DSLs that build out the anticipated cloud configuration, then post the configuration and ensure everything is provisioned. This should be easier to maintain than a yaml file with extra templates, all while being more powerful. Second is AsyncAPI. This is what brought me in. It still seems relatively young; however, if we can build type safe Kotlin multi platform clients, this could drastically ease building mobile and web applications. This in turn would drastically reduce the amount of glue code that needs to be written.

Pain Points

The biggest pain point of this is the support of several different properties in JSON Schema.

  • additionalProperties is a list of valid types that can be used for any properties not explicitly outlined.
  • patternProperties matches a regular expression, and then provides matches for each key.
  • oneOf, anyOf, allOf is like a discriminated union that can essentially be backed to a sealed class. Validators would need to ensure that only the desired amount was set.

The bigger pain point is the semi dynamic nature of the two extra properties. A data class object would need to be extended with any additional properties or pattern properties. For pattern properties, we would need to validate any keys being set to ensure they match.

Lastly, these fields are not restricted to local. If you don't see them in the current scope, you traverse upwards until you either find them or don't.


This is starting to feel like SOAP to an extent, but less obtuse, if that makes any sense. As we move more and more into cloud and micro service development, warranted or not, not all teams may be using the same language. The lynch pin of a good micro service architecture is resilient service boundaries.

With a contract first approach and a language agnostic definition, we can now easily share how a service works and talks. This allows us to easily port a Java application to a python application, or vice versa.

I find it interesting how we're sort of re-learning past patterns and applying modern tweaks. This feels like some older WSDL and SOAP technologies, but less obtuse and lighter. I was writing some XSD definitions earlier this year, and I will gladly take JSON schema.

In closing, this is very exciting to me. We have a standard for the below:

  • Deploying and maintaining infrastructure
  • Building a service, including routes and data types
  • Building a client, including connection and parsing