flowcus.bar VS graphql-api

I'ved added screenshots and a brief description.

https://github.com/indiedevai/flowcus.bar/

I created an open source library that turns structured text data (YAML) in a Git repository on the fly into a GraphQL API with CRUD queries / mutations.

All that is needed in the repository is a plain text GraphQL schema file that defines what the data structures look like. The Git repository itself can be located on GitHub, GitLab, or in the local filesystem.

https://github.com/commitspark/graphql-api

I'm working on https://commitspark.com , a headless CMS where all data is stored in a GitHub repository with branching/merging workflow support for content.

Reading/writing content from/to GitHub happens through an Open Source API library I released. For the content data schema, I simply require a plaintext GraphQL type file inside the repository. The schema then automatically determines the API structure as well as the editor-friendly UI that I can generate on the Commitspark website when you log in via GitHub.

Even though Commitspark is already publicly available, it is still 100% a side-project that doesn't earn me any money (yet).

Hi HN,

I built Commitspark, a Git-based headless CMS that runs on top of GitHub.

The primary purpose is to enable non-technical content editors to take advantage of Git workflows based on branches, pull requests and merges, without them having to learn Git.

Behind the scenes, everything content-related is driven by GraphQL and an open source library I released ( https://github.com/commitspark/graphql-api ), and for all the workflow features like PRs, commenting and diffs, I built a CMS-centric view onto GitHub using the GitHub API.

For content editors, this should feel the same as working in any other headless CMS, except now with support for much more powerful workflows. For developers, this means all the strengths of Git and GitHub can now also be applied to content (pipelines, tags, commit hashes for caching, branches for migrations, etc.).

There are many other things I am also excited about here that I'm happy to discuss, so please leave your questions below.

Have you considered that content might come from Git? If so, how would content branches fit into this?

(Disclosure: I'm building a library that turns a Git repository into a branch-enabled GraphQL content management API. See https://github.com/contentlab-sh/contentlab )