This blog post describes a prototype that uses static JSON files exported from the Kontent.ai headless CMS that contain data and content used to control a website.
Update 15.Dec.2025: After years of frustration with WordPress, I am finally abandoning this blog. The content will likely stay here for some time, but new content will appear here:
I previously developed a prototype that used JSON from Kontent.ai Webservice APIs to control a website:
Subsequently, I developed a prototype that exports JSON from Kontent.ai as static files:
I decided to try to update the former solution to use the files generated by the latter.
Retrieving the JSON from the file system instead of the API is easy. Kontent.ai entry references include their unique codename. I just stored all the JSON files in a single directory using their codenames. This works, but might not scale well. One approach to avoid putting all files in a single directory might be to store entry is in directories created by slicing what would otherwise be the file name, something like such as /files/n/a/m/e.json.
For me, the biggest programming problem was that I don’t think I’ll ever quite understand asynchronous programming in JavaScript. This is relevant because the code uses fetch() to retrieve entries, which is asynchronous and seems to require a lot of hoops for relatively simple things (and it seems like React complicates that). I guess this infrastructure addresses significant technical issues, but it caused some challenges because the code that accesses files needs to do more fetches than the code that accessed APIs.
Another issue was some JSON structure differences. This is one reason to normalize or flatten data before using it. But the biggest issue was that the Webservice APIs can expand referenced entries within an entry, so you retrieve an entry, and it contains other entries, where the files always represent individual items, requiring their retrieval in sequence.
For performance, the server application should probably access files, but clients might invoke the CMS vendor’s webservice APIs on their CDN, which might provide better performance. CMS preview should probably also use APIs. Maybe I’ll try to work on a version that supports both.
For now, the updated code is in a branch:
deliverystack.net 