@U0MKRS1FX

thanks for the mention, @U07FCNURX! Back-end is typescript and AWS only at the moment.. and it’s very (very) beta 😿 And I’m not sure if it covers the category “headless CMS”, as there are no tables and schema, it’s more of a “google docs with react components” type situation

Then it isn't unfortunately suitable for my use case, but thanks anyway 🙂

Need a proper database, need (preferably) graphql endpoint and need to be able to run it on google cloud 🙂

I have a feeling I should do this myself but unfortunately I do not have time for that

yeah, that makes sense! Most people seems to mean tables and data structures with automated GUI when they say “Headless CMS”

Yeah. This is a proper use case for a headless CMS with multiple delivery channels and so on

there’s always the #1 in this space, Sanity. Not self-hostable though, but people have great success with web hooks that lets you store final output locally

Currently working with Keystone

Evaluated about a dozen differnent alternatives before I went with that

But that too is proving to be... Sucky

The fact that it doesn't log almost anything (even when setting their logging settings to something sensible) doesn't really increase confidence for production usage

what use case lead you to the requirement of it being written in Clojure? In my experience, a headless CMS is usually a black box that you get data from via APIs and the implementation language is not really relevant

No other use case but I work fastest with Clojure

And I need to modify stuff heavily

...when we go forward

I suppose headless CMS is many things… I’m not that familiar with the node library versions of this. You’re looking for something with a programmatic API that you can embed in your own system?

Well, the story is a slightly more complex. Naturally, there's a tight(ish) deadline and need to get stuff out live by then. There's specific feature set that needs to be finished. Then there's the future vision and what is needed there

(I’m just asking for my own curiosity now, and not really making any attempt whatsoever at helping you find a good CMS 😇)

My current plan is to take a headless CMS and use that for the time being but most likely we'll write everything from scratch a bit later when we have more resources and time

GraphQL endpoint is preferable due to it's flexibility especially if one takes a blackbox kind of CMS implementation

But naturally it's not a hard requirement

This is a bit of a rant from my side and I guess I'll keep on working with Keystone for the time being but if there had been a really great alternative for Clojure I would have been tempted 🙂

sanity + webhooks is definitely worth looking into, at least! The CMS itself is a black box, but all changes gets posted to a webhook, where you can write any code you want in your preferred programming langauge, and extract data from Sanity through its APIs, and store locally in your own system whatever you need

I did look at sanity and didn't go with it, can't remember anymore what was the main reason for it

One of the things that bugs me a lot with all these nodejs implementations is their insistence on creating their own CLI tools for running those. Why? It's not like they are being setup by software development imbecils? Have they ever heard of IaC?

I do not want stuff like xxxx deploy heroku

All of this brings me bad vibes from ORMs where they make easy things even easier and hard things impossible

Simple Made Easy. They do not do that

haha yeah, having a good CLI UX and being fancy etc seems to be something the Node crowd enjoys 😄

Configurability should be the king

So that the product they are creating doesn't have to try to solve all use cases

You want to store images somewhere? Great. Provide out-of-the-box providers for S3 for example. But also provide an easy way to plug your own provider there that you can write if you have a different need

#xtdb + #juxt-site from #juxt may be of assistance - it's a GraphQL resource server that can be used as a headless CMS

I actually looked at that combo with interest

But it is maybe a bit too much work right now. But I am going to take another look later when I hopefully have more time for this

We’ve had great success with Sanity and a Clojure backend

We treat Sanity like a database with a really good editing interface, like @U0MKRS1FX mentioned

I was going to say https://www.hyperfiddle.net/ but I think it's still in development.

+1, currently I'm stuck with strapi because it has two main features: user login connectors and the ability to modify everything in the codebase per instance, aka I can white label strapi or add functionality easily. This is not available from Supabase etc

However it would be great if there's one in clojure so I can just use clojure instead of NodeJS

It would be easier to extend the normal markdown changelog conventions with more metadata than to make custom visualizers and/or editors for this new markdown format. So it doesn't seem worth it to me.

The only reason we use plaintext files for this kind of thing is because git is file centric and doesn't allow you to store structured data in it

I would much prefer to store changes to structured metadata about the code alongside the code; I wrote a bit of a rant about this a while back https://respatialized.net/against-metadata.html

In github markdown you can also add tables, diagrams, etc: https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/

IMO we should stop storing important information about our code and its history in flat file formats where composition is impossible, consistency is not enforced, and you have no query capabilities, so I'd argue that EDN doesn't go far enough

But it's still an improvement over endless "update README.md" commits

It sound to me like too much effort that will result in little adoption anyway You can use the fanciest changelog format and still screw up :) i.e. it all comes from a human. In the end there a couple things that don't lie: • Diffs, e.g. I post https://github.com/seancorfield/next-jdbc/compare/v1.2.780...v1.2.796 when suggesting an upgrade at work • Specs/Schemas (sadly there's nothing even close to standarization in ... so no automated tooling would shine today)

It wouldn't be too crazy to build today a tool that compared the ASTs (or kondo analyses, w/e) of $lib v1 and v2. It could tell basic things like var changes, arglist changes.

I am afraid @U04V15CAJ beat us to that, again 🙂 https://github.com/borkdude/api-diff

What I'd like to have to support that is semantic diffs,think next level from structural diffs ala edit script

@UK0810AQ2 https://difftastic.wilfred.me.uk/ diffs on tree-sitter nodes/trees.

The clojure deps tool "outdated" will link to a github diff range of it can. I was thinking about trying to find and add change log data to that.

Edn would be an improvement, but not by much because that information is meant for humans to read mostly.

Like others have said, structural diffs would be the truest way to know changes, but that's too much effort for most users to go through to read. So your still going to want to have a high level overview.

Thanks for your opinions, very interesting I guess that beyond EDN, what I was really looking for is just better programmability and your answers go towards that.

I have not used metadata on transients, but clojure has 2 ways to attach metadata

One for mutable things (identities, references) and one for immutable values

transients are mutable

Ah. Thanks. I’ll hunt down the with-meta equivalent for mutable things. That’s a good steer. Thanks!

I also suggest considering the alternative to transients and metadata, things are usually better without them

I usually don’t use transients. This is a performance sensitive use case though, and it’s a significant penalty to use a plain map here.

If you look at into, it turns the collection into a transient, pours the values in, makes it persistent, then copies metadata

That’s what I’m doing now too, but I need to gather the metadata during a reduce where the accumulator is a transient.

Why not have the accumulator be a pair of the transient and the metadata?

That’s actually a great idea….

Thank you.