I am an old database guy. I got my first job working on databases in COBOl in 1987. I have worked with almost every database platform out there, and I love data. I remember writing my own indexes, relationships, and other things we take for granted now. I remember being religious and dogmatic about the platforms I used, which included FoxPro and eventually Microsoft SQL Server. I have grown out of any dogma for any platform, tool, or specific approach, but I continue to manage quite a bit of data for my personal and professional pleasure.

Data is core to API Evangelist, and my API industry research. Even though I still have an Amazon RDS MysQL core to my data operations, this centralized approach is slowly being cannibalized by a more distributed, static, JSON and YAML, and Jekyll driven vision. Increasingly my data is living in the _data folder of each static project repo, being hosted on Github Pages, as well as some specialized Linux Jekyll EC2 deployments I am working with. I do not think this will ever be something that entirely replaces my old, more centralized approach, but it has grown to be a significant portion of my operations.

There are many issues with this approach, keeping things up to date, providing a comprehensive search, and other things are still challenges for me. However, the static nature of both the UI, and the data layer for this projects is proving to have benefits that far outweigh the challenges. The openness and availability of the data and content that drives all my research, project sites, and tooling is refreshing for me. I'm also enjoying having hundreds of very static, cached, distributed websites, and tools that don't change -- unless I direct them to with a publish or a push.

One area I am still exploring in all of this, is the pros / cons of delivering UI experiences with pure JavaScript which consumes the JSON, a more heavy Liquid experience which also consumers the JSON, or take it to new levels with a combination of the two. Some of the stuff I'm doing with an APIs.json and OpenAPI Spec driven documentation which uses Liquid, and JavaScript feels liberating as an approach to delivering developer experiences (DX). If you haven't played with _data folder + Liquid in Jekyll, I highly recommend it--it is a different game.

Anyways, I haven't had much time to talk about this shift in my data management approach, so I wanted to capture some of my current thoughts about the potential of Jekyll as a static data engine--we will see where it goes for me.