Use Content from Headless CMS API?

I would like to use a headless CMS like as authoring environment.

How would I have to use Zola to achieve this? Must I render API content into the file system?

Thx, Andreas

In the Javascript ecosystem gatsby seems to be the choice.

There was a discussion in GitHub I believe about that. I’m not sure yet how that would work with Zola.

1 Like

What about something like I just did a half-ass try to use forestry for my zola site and it seems possible. To get preview functionality however it seems like they need to integrate zola as they have done with Hugo.

Ideally we could build something like forestry but for Zola, we can’t expect companies to support it and it’s not open-source

Can build a program to consume the API and output files to the content folder? I’m not sure how to represent the files, guess it would depend on the metadata that the CMS API provides.

Having a “zola-source-graphql” would be a huge advantage to support headless CMS APIs

If there’s something I really don’t want to deal with in Zola, it’s GraphQL

1 Like

I don’t know if it’s really the same, but I am in big need of being able to load my pages from an API during build time. It’s the only thing stopping me from moving to Zola right now. I haven’t found anything about this in the docs, so I assume it’s not currently possible. It’s a huge selling point for some other static site generators.

1 Like

What exactly do you want to do?

This is the similar topic with Hugo:

I need it to be able to build my pages based on data stored in a database. So I’d fetch the data from an API during compilation, then create my pages based on it. In my case I have an API where clients are able post, update and delete articles. And I want to be able to build a Zola site based on that data every X minutes, or on demand.

Gridsome has this functionality for example, however they store the data in a GraphQL data layer, which I read that you don’t want to deal with.

The reason why I’m not using Gridsome is because I need fast compile times. Only Zola and Hugo fits that criteria as far as I know.

That’s a great find, it seems like they have some good ideas.

I don’t want to deal with it at Zola level. GraphQL is just a POST with some specific DSL in its body from the client POV. If we support an API, GraphQL should be automatically supported.
FYI this is not planned for the immediate future because the next version will focus on proper/full i18n support but could be looked at afterwards.

We can definitely think of how it should look right now though, thanks @zoosky for the Hugo link!

1 Like

Thanks for taking your time to reply @keats.

I don’t mind waiting for it. Maybe Hugo will find a good solution first that Zola can get ideas from. But I do think that this is a crucial feature in order to take Zola to the next level. If I get good enough at Rust I might be able to help implement it (if I still need it by then). Right now I’ll have to use a Rocket server that compiles Tera templates on demand.

Great work on Zola and Tera so far!

1 Like

Another interesting user story and use case from Hugo ( feature req)

We could maybe do a flutter + rust kindof deal. At that point we could have a desktop/web/mobile client side GUI solution that plugs into a repository/folder/database etc.

I have done it and it is a bit of a pain maintaining C interop interfaces in dart and rust. So the API will need to be small. This would be a chance to make a standard API that the other site generators can use to plug into our frontend.

We could start off wrapping the CLI with a desktop app with local folder/git support.

EDIT: On second thought, could just push strings through the zola main function for first c interop pass.

1 Like

I successfully got netlifycms to work with Zola. I hacked around with their examples built using Hugo (which has a similar folder structure) and it worked great!

I am literally doing that right now. I am still trying to get past the login.

Any chance you have anything to share? Are you using netlify services? I am using my own stack for building and hosting: bash, tekton, k8s, nginx.

Long term, it would be nice to have a vendor neutral solution.

1 Like