Netlify-cms: Question: Would writing a backend for PostgREST be feasible?

[cies]

Hi all!

Netlify CMS is amazing! But for the usecases I mostly have to deal with I'd 100x prefer a relational db over Github repos. Other apps need to be able to extract data from the backend, and since the data fits very well in tables: why sould I want a repo with files?

Now there's this wonderful project called PostgREST (link to docs describing it's API) that sit between PG and the web.

There's already one project that wants to be an interface on top of PostgREST, it uses the admin-on-rest project: https://github.com/tomberek/aor-postgrest-client

But this project is not as feature complete as Netlify, most notably the editorial workflow is missing. This is of course what Git brings to the table, but I do not think it is too hard to facilitate a similar workflow with a relational database.

Now my question is... Would it be feasible to make a PostgREST backend for Netlify CMS? Probably some conventions need to be made to facilitate the editorial workflow; or is it simply not possible to have a database enable this level of collaboration?

p.s.: There's also a generic JS wrapper over the PostgREST API: https://github.com/calebmer/postgrest-client

[Benaiah]

It's almost certainly possible to do, but I don't think it's likely to be something the core team can get to quickly. We'd welcome contributions towards this - one of the things that will make this much easier to merge and maintain will be more testing for the backend, so contributions in that area would be awesome.

[erquhart]

This would require the git-centric nature of the CMS to be completely abstracted into individual backends. I'm honestly uncertain how I feel about supporting a non-git backend.

That said, we'd like to see backends that exist outside the repo as plugins, and it really shouldn't matter whether a backend is git based or not. If the backend you're describing really takes shape, it would be a good reason to go ahead and make backends a pluggable interface via some sort of registration.

Interested to see where this goes!

[Benaiah]

Yeah, I definitely think this fits better as an extension than in the core, due to the fact that you'll have to reimplement a lot of the Git semantics.

[cies]

If I understand you correctly writing a non-git backend involves a lot more then writing a git-based backend. I saw the examples of, for instance, the Gitlab backend...

https://github.com/netlify/netlify-cms/pull/517/files/1b8f2e8d99810601358b7b527ace4cd663ce2d4b

...and thought "if that's all then rewriting that to use a db should not be too hard".

But there's a lot more code specific to git, probably allover the codebase? Could anyone maybe point me a bit in the right direction?

[Benaiah]

No, the stuff in the backend is where pretty much all the Git stuff happens, but our semantics our pretty centered around how Git works. It’s definitely possible and probably not terribly difficult to emulate these in PostgREST. Our concern has more to do with the idea of having this backend in the core, which would require us to maintain it and would make feature delivery more difficult. The best way forward for this is probably defining a plugin API for backend, in which case you could handle it however you wanted.

[cies]

Ok clear. I understand you do not want it in core, for maintenance reasons. On the other hand I think that by not having a db backend Netlify CMS is needlessly limited to niche (static sites). Besides being a more "dynamic" storage medium, databases are still the norm for storing structured data that fits in tables, and thereby provide great interop with many other technologies.

[zanedev]

Just wanted to chime in a bit about the usefulness of structured/dynamic/relational data for people that might be new to the JAMstack. NetlifyCMS is JAMstack specific so it is being built for a whole different paradigm/ecosystem and it's certainly not as small a niche as a "static" site sounds.

The dynamic part you are referring to could be handled a few ways using modern JAMstack tooling:

• a service or api backed by a postgres db could be injected into the build process when the site is built or
• the result of an api call can be injected into the cms static data stored in github as needed in a custom editing widget scenario if it's needed at editing time. Most static site generators let you inject dynamic data into the build process.
• the client (browser/phone/etc) is expected to handle most if not all of the dynamic legwork after the site is deployed, for instance accessing a service, postgres backed database to get dynamic information during either editing or deployed (static) site.
• the cms itself can work with any type of structured data like markdown, yaml, you name it that can have relationships if you so choose.

So the focus is more on injecting dynamic data at build time, or through the client at run time. The benefit here (among others) is no need to rely on any database or api to use the cms. Since git provides everything needed for the JAMstack workflow there really is no need for the db part at the cms level for most (if not all) sites.

I think @Benaiah's comment makes sense, it's not just the maintenance overhead, it doesn't really fit the core use case of the cms so probably shouldn't be in core but hey it's open source, if it can be extended to use an api or db then cool. If you just want to get it done fork the project and create an api/db powered version then later integrate it back as a module/extension to the core.

[erquhart]

I've been considering how we're pushing toward support for assets from non-git sources. It's really making me rethink why we can't handle non-git backends. Truth is we totally can, it's just not a primary use case at all. Most folks are running a static site generator in a git repo, where both their site and content are stored.

That said, if the community contributes toward making non-git backends work, I'm in favor.

[Benaiah]

@erquhart agreed - while it's not our focus, there's no reason the CMS can't support it, and I'd be very supportive of a community effort to build a backend based on PostgREST or similar tech. Headlessness comes with a _lot_ of flexibility!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[erezrokah]

Closing as stale with the note we still very much into supporting the community adding custom backends and using the GitHub backend as reference