I’ve blogged about the DataObjects concept in the past. I’ve implemented it in a few different forms, but I’ve never been fully satisfied with it and continued kicking it down the road. The concept is similar to DynamicData, which was implemented in the Xaraya CMS. DynamicData, written in PHP, allows you to extend a content type or even build a new one by attaching data fields to it. Instead of having a set schema, a content type could be extended as needed. This single capability made Xaraya one of the most flexible CMS’ of it’s day.
In my Clay CMS, DataObjects was partially implemented as a plugin system. The difference between it and DynamicData was the fields had to be implemented by an application (often extending other fields) and could then be attached to another application. It had basic field types within DataObjects, but it had no dedicated data source. The basic fields were hardcoded into the application and could then dynamically extend other applications via DataObjects. Clay’s DataObjects could also be used as a web service to provide plugins to external applications. This was how my widely used Zillow service was implemented and still is used by 100s of real estate websites – it is currently deprecated and will likely be re-implemented with this new system.
My next implementation of DataObjects will power an extensible GraphQL API. It has been my side project, so it’s coming along slowly, but I’m hoping the slow pace will contribute to refinements my previous implementations were denied. This API will initially be entirely data driven and confined to an API service, until I can create enough frontend components. The idea is to be able to create entire backend APIs with a data driven structure, provided by GraphQL. The overlying concept isn’t new. This API will allow you to create data structures without interacting directly with a database and the resulting structure will be strictly typed by GraphQL. You can then mesh these structures together to be used however the application needs them. It’s a headless CMS, but you build it to fit your needs with GraphQL mutations and then consume it with GraphQL queries.
I’ve attempted this previously with a REST API. The dynamic URL structure was it’s failing, as it become more and more complex as the structures grew. I also attempted a generic URL structure, which was better in some way, but also added restrictions I wasn’t comfortable with in the end.
This has mainly been a weekend project, so it will take a while to fully implement. I’ll also be going through a career change in the near future, so that could accelerate or slow it down, depending on time restraints. The end goal is to allow developers to deploy web sites or web-based services without the need of hosting their own API backend, but with the capability to design their own GraphQL schema.