| 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 see that. And I saw that you have probably tick most of the boxes in my list.
Excuse me for my late reply...
> Along with REST endpoints
Are they fully spec'ed (as in OpenAPIv3)? And may the spec change based on how you setup/evolve your site?
I'm really, really done with writing boilerplate, a full spec (OpenAPIv3 or GraphQL) allows me to generate a client lib, and these spec standards have very cool generator for them.
I went deeper into Payload, and the REST endpoints are unspecced (just docs for the endpoints, not formal spec for endpoints or their bodies).
> full text search
I mentioned it because it is a really hard problem. Keeping the search db and the main db in sync is hard, i18n when doing full text search is hard, allowing customization of the full text search engine is certainly also going to be hard. It would be great to have something that abstracts some of these away.