graphql-api VS Filestash

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 )

Filestash — A Dropbox-like file manager that connects to a range of protocols and platforms: S3, FTP, SFTP, Minio, Git, WebDAV, Backblaze, LDAP and more.

I made https://github.com/mickael-kerjean/filestash out of the need to collaborate on org mode documents with non emacs users. Once the first release was done, I got to reflect on the infamous top comment of the Dropbox HN to make an attempt at abstracting the storage aspect of Dropbox so those org document could be made stored on a FTP server, SFTP, S3, ....

> we need an abstraction for just this. "Bring your own storage"

I made exactly this: https://github.com/mickael-kerjean/filestash and there's an API from which you can abstract any kind of storage: S3, SFTP, FTP, GIT, WebDav, Samba, Local FS, NFS, Backblaze, Storj, Artifactory, .... There's even some funky ones like Mysql from which you have an abstraction where first level folders are databases, second level folders are tables and files are the actual rows

Yes, I rewrote my react app onto vanilla JS using nothing else than rxjs, didn't have the time to document it all yet but it looks like this: https://github.com/mickael-kerjean/filestash/blob/master/pub...

I'm not familiar with Cloudreve, but FileStash is a similar application often recommended on this subreddit.

I do use them on my OSS work (https://github.com/mickael-kerjean/filestash/tree/master/pub...) which is used by many thousands of people

- [2] current state of the rewrite where you can see this pattern in action https://github.com/mickael-kerjean/filestash-rewrite/tree/ma...

https://github.com/mickael-kerjean/filestash

This is what I wish Dropbox was, a simple layer that make interacting with your FTP server easy so nobody has to own your data. The end game is both to be feature complete with Dropbox and be able to change every aspect of the application through plugin so everyone can get out what they want from it.

> but I don't think its the companies responsibility to give back to open source just because they use it

As someone who does quite a bit of OSS, the reality is most people are asking for things but aren't willing to pay for it. Take Microsoft, I had one of their employee asking me to support their azure stuff: https://github.com/mickael-kerjean/filestash/issues/180. When I found out the dude was actually employed by Microsoft, he started to talk some nonsense and ended up running away.