jobsdone's comments

What bugs did you run into? This sentiment is not shared by the Payload community that I've seen.

I built several large Laravel projects before launching Payload. It is cool to hear from other Laravel converts. It wasn't the PHP part that I minded, it was having to do too much work for the backend and then also having to come up with the admin UI from scratch that did me in. There were some packages but nothing worked quite well enough.

On the other DBs topic, SQLite is just around the corner ;)

So glad you and others are liking the direction. It is true what they say, listen to your users.

I've been building web apps for more than a decade. From an agency and consultancy perspective, developers can build truly amazing things on the web for any client need. The tools for building websites and apps have gotten better and better, the side-effect has been a mindblowing amount of complexity being introduced. You either end up with some no-code solution that is scoffed at by any serious engineer, or something built out that requires a senior engineer to maintain.

This ultimately is bad for the client and developers who have the resposibility of learning a dizzying amount of tooling just to make something that works. It shouldn't take a computer scientist to build a website.

To combat this we're excited to release a new package that simplifies your stack into a single repo with Next.js and Payload that can be run serverlessly. The beauty here is that there is very little devOps, generated typescript types unified across frontend and back, and the elimination of HTTP API calls between application and backend. https://github.com/payloadcms/next-payload

My co-founder of Payload, James Mikrut is doing a livestream with Vercel's Steven Tey to shed some more light on what we're seeing: https://www.youtube.com/watch?v=TWkR-OPXKRU

Forestry is shutting down and pushing people to Tina instead. I guess it is the same company? I don't really know.

Oh! I misunderstood your point about versioning. I was thinking versioning of content but you're talking about the API.

That is a harder situation, I think my approach here would be to route requests to the api version on a separate new instance, `v1.example.com/api`, `v2.example.com/api` for example. Any way I can think of handling this scenario in the application layer gets messy right away, but maybe there is a good way I haven't thought about yet. I'll keep this in mind in case as a future feature we could build in or make turn into a plugin perhaps.

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?

Haha, you called it!

I guess we'll have to update those screenshots! :)

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.

Serverless has been asked for quite a few times and we've gone back and forth on it. We want to keep an open mind, but the business case to build it isn't there at the moment. That could change if somebody wants to sponsor that development or some OS devs open a PR or build some porting plugins.

It could simplify deployment and have some other benefits, but we always go back to the fact that even with a sleak serverless architecture, you're still hitting a centralized DB. It really weakens the argument for going serverless.

Absolutely! Thanks for linking this.

I've heard good things about statamic also. How do you feel about their pricing model?

The point here is that it isn't just a tool for content. The way I see things, there is no useful distinction between content and any other kind of data. Payload makes it trivial to set up custom data structures and manage it.

The tedium of development in my experience is building CRUD—whether it is for a SaaS app or anything else. When you're rolling a project using a framework you've got to set up a database, write the API logic and build an admin UI to manage that data. It is complicated and time consuming work even with a great framework. To be able to skip all that is a massive advantage.

I personally would not build a SaaS app on Wordpress and ACF, but I would use Payload to build just about any custom business app.

Next.js works great with Payload. One cool feature of Payload is the Local API, which works awesome for server side rendered pages. You get your data from Payload right in your `getServerSideProps` functions.

You'd be interested in the example repo: https://github.com/payloadcms/nextjs-custom-server

The example is set up to manage Pages, but with a few tweaks you'd be able to manage blogs posts instead.

You're not alone.

I ran a team at a weekend hackathon event for non-profits. We needed to finish building their new site on the latest version of Drupal. I had SEVEN devs working on a 5 page brochure site with a page to manage events and we couldn't get it done! I felt terrible leaving it incomplete at the event, but honestly, with Drupal as the tech stack—my hands were tied. Luckily the developer who started the work was able to finish it a few months later.

To do it all over again, I would have convinced them to throw away what they had and use a different platform. If we used any other tech stack, we could have finished and launched the site during the event.

That was the first, and last time I touched Drupal.

Hi! I'm Dan, Payload co-founder.

Prior to building Payload I was a consulting full-stack engineer. I have built large web apps using Laravel and have rolled my own admin UI a dozen times and I've worked within the official 'Nova' package too. Laravel had a few open source options which I didn't try as it seemed like support was better with Nova. The project I built went okay, but it was a ton of work over what you can do with Payload.

To add a field you have to: 1) create a migration to add a column to the DB 2) add your field to the model 3) define the field again in the nova "resource"

In Payload you do all of this in one place. Every field you define will have the proper DB schema, API and admin UI in a streamlined way without having to touch your app in a bunch of places.

Two other things that made me scratch my head while using Nova specifically. The first, I had to cobble together plugins for building blocks for component based field defintions and image uploads, but these didn't play well together at all. How could image uploads and blocks not be built-in core features? The other pain point with Nova is that it isn't refined at all, and they say it shouldn't be used for customer facing UIs.

Do you have a favorite framework/package you would suggest for mananging admin UIs and APIs that do a great job?

Thanks for sharing geox! I'm part of the team at Payload and it's a really exciting time for us after going open-source a month ago. Now we're in YC S22 and working full time and build way faster.

We're striving to make the developer experience the best of any tools around. Would love to hear any and all feedback!

Founder here, we've been at it for 3+ years of development, released at the start of 2021 and the product itself is closing in on 3000 commits. This past week we have seen some community plugins start to roll in!

When we started this journey in 2018, there wasn't a headless CMS out there that passed our standards for features, quality, ease-of-use and extensibility. We were still building Wordpress sites and bespoke apps on different frameworks because no CMS had it all. Now we have customers discovering that Payload is perfect for SaaS apps, eCommerce sites and many other needs.

It has been a journey and as the roadmap shows, the grind will continue. Thanks for checking us out and let us know what you think in the comments. :)