Launch HN: Payload (YC S22) – Headless CMS for Developers

How does this compare to KeystoneJS, another TypeScript CMS? https://keystonejs.com/

This is a great list! I don't see anything in here that Payload doesn't handle. I'll try to address each.

> allow me to create a localized content (you seem to have this covered).

Localization can be done on any field(s), at any point in your content structure .

> a good story for blobs (images, video, PDFs, etc).

You can have as many upload collections and set mimetypes. Payload saves to a local directory in your Node app or you can use our cloud storage plugin for S3/Azure/GCP.

> integrated full text search (I do not want to set up elastic search when using a headless CMS saas).

Payload has a lot different querying options and you can get creative with relating content to one searchable collection, but we still recommend a proper search tool when you have complex filtering and searching requirements or massive collections which are better optimized elsewhere.

> fully spec'd API (when I have defined a content type, I need some API spec to be updated; openAPIv3 was good, GraphQL is better: so I can generate a client lib).

Along with REST endpoints, Payload opens up a full GraphQL implementation with complete schemas based on the config you provide for queries and mutations. It also can write these out to a graphql.schema file using a built-in command.

> some mechanism to know the API was updated (so I can show the "a new version is available, the version you run may no longer work in certain cases, please click here to use the newest version" message somewhere).

This would be up to your implementation of Payload and your frontend. You could make a field for publishDate or increment a version number to handle this scenario and query and compare based on that.

> a story on content blocks (say: text, image, text, quote, text, author card) vs embeddable content in text blocks (say: a text block with a way to embed images/etc into it); the latter is really hard to do right imho.

Payload's richtext field is capable of embedding relationships and file uploads so you can do the hard thing or you do predefined blocks for your content editors to use like you said too.

We really put in the work, I'd love to hear from you if you try it out.

I've explored the options in Laravel and did an entire project with Nova. Based on that, it wasn't as straightforward of an experience as I would have wanted. You still have to learn the ins-and-outs of the framework and then also still define your editor experience.

I haven't done the same exploration for Rails gems. I'd be curious, which have you have used that take care of the CMS and admin panel requirements?

You still have to learn the "ins-and-outs" of Payload also for this to work so what's your point? Based on my experience with npm based projects, I bet you x,xxx dollars that even an npm install will start vomiting 3 months after you finished your project. This ecosystem is cancer and I blame designers trying to do programming work because...it's javascript, what can go wrong? Everything seems like a complete hack in this space. Tools are built based on unicorns and rainbows and not logic, maintenance and backwards compatibility.

Do a project now and come back 3 months later and update it to latest versions to see what happens. Compare that with a Django app + django admin afterwards.

I totally hear what you're saying. One thing I can say extremely confidently is that while my agency was eating our own dogfood with Payload during 2020/2021, we released some large projects on Payload and have kept Payload updated in all of those projects since. It's been seamless. A large focus of ours since the beginning was to identify an API that could reduce breaking changes to an absolute minimum and to restrict the use of other packages wherever possible, to avoid the NPM whirlwind. Our config-based approach has delivered exactly that. All of our projects, and our customers' projects, built even before beta release have been updated without issue. But this is certainly systemic to NPM and especially if you look at packages that are of lesser quality. That's the classic downside to the way that the JS ecosystem does things - it's basically open-ended at every turn. Even with React. But I am very confident, having had experiences very similar to yours, that it's handled quite effectively with Payload.

On another note, one of our goals with Payload was to rigorously minimize the amount of learning that you have to do to get up and running with Payload's specific conventions. This was a huge requirement of ours while we designed our initial API. We've always _hated_ having to learn the intricacies of another platform like Drupal or WordPress before being able to be proficient in those systems. It's like you have to get a degree in the CMS before you can use it rather than sharpening your skill set with the underlying language.

Payload's conventions are quite flat and are all config-based. From there, you write your own code to do whatever you want in the conventions that you're used to.