Over a million developers have joined DZone.

The Potential Of Jekyll As a Static Data Engine

The API Evangelist talks about alternatives to data storage.

· Integration Zone

Learn how API management supports better integration in Achieving Enterprise Agility with Microservices and API Management, brought to you in partnership with 3scale

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.

Unleash the power of your APIs with future-proof API management - Create your account and start your free trial today, brought to you in partnership with 3scale.

api design,api development,jekyll,static

Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}