Future Directions for Payload CMS — What’s Next?

[gunwixor]

Overview:

As Payload CMS continues to grow and evolve, it's important to reflect on the future direction of the platform. This issue aims to spark a discussion on potential new features, improvements, and areas for expansion that could benefit both developers and content creators.

Key Areas for Consideration:

Enhanced Customizability:

How can Payload improve its flexibility for developers?
Should we consider introducing more out-of-the-box options for templates, custom fields, or integrations?
Community-driven Features:

How can the community have a more direct role in influencing the roadmap?
Could we explore community-driven plugin ecosystems or allow more extensions?
Performance Optimizations:

As content management grows, so do performance concerns. Are there specific areas where we can improve the speed and scalability of Payload, particularly for large projects?
Future-proofing Integrations:

With headless CMS becoming a central part of modern stacks, how can Payload stay ahead of trends in API-first and headless architectures?
Could we focus more on seamless integrations with emerging frameworks and platforms?
User Experience (UX) Enhancements:

Payload CMS is already developer-centric, but what about the non-technical users? Are there UX improvements that can make it more approachable without losing its power for developers?
Call to Action:

Let’s gather ideas from both the community and core team to shape the roadmap. If you have suggestions, concerns, or ideas, please add your thoughts here.

[RafalFilipek]

Hey,

@gunwixor This is great, thank you for initiating this!

Here's the first batch of thoughts :)

1. DiscriminatedField: I often encounter situations where a UI element needs to perform different actions, for example:

   type Action = { type: "LINK", /* some fields */ } | { type: "MODAL", /* some fields */ }

   Currently, I'm using admin.conditions for this, but it requires additional mapping to match the elegant typings I have in my application. Assuming the discriminator can only be based on static values, I'm thinking of something like this:

   {
     type: 'discriminated',
     name: 'action',
     field: 'type', // name of the field in generated interface
     as: 'radio' | 'select' // how to pick type
     mapping: {
      'LINK': [Field[]],
      'MODAL': [Field[]],
     }
   }

2. I can't understand why optional fields are typed as field?: string | null | undefined. I've tried various things, but it seems that's just how it is. An option to disable the null typing would drastically improve the DX from a typing perspective, where (at least in my case) null is used very rarely and always intentionally. Perhaps a nullable option for fields with a global fallback in payload.config.ts?

3. @/payload-config is a nice convention, and I understand why it's used, but it requires special workarounds when the project is developed in a monorepo and has a global task that checks the correctness of typings. Maybe there's an option to use relative paths.

4. When a collection/block has many levels due to the use of groups/rows, it would be nice to be able to assign them a level. With each nesting, the size of the header could be smaller.

5. breakpoints could accept height: 100% :)

6. From the UI panel perspective, a primitive-array field type would be useful. Currently, when we have a type defined as an array, it's very verbose.

   {
     type: "simple-array",
     name: "bullets",
     element: "string" | "number" | "date"
   }

   Such a field would only have a name and a list of text fields to fill in.

7. With headless CMS becoming a central part of modern stacks, how can Payload stay ahead of trends in API-first and headless architectures?

   I'm 100% sure that @payloadcms/sdk and the built-in option to generate OpenAPI specifications for all endpoints will change a lot.

[jeanlescure]

Hi Payload CMS team & community 😄

After having gone through several Headless CMS solutions (Strapi, Directus, etc), and having experienced the growing pains of migrating from Payload v2 to v3, I foresee staying with Payload for years to come... hopefully 🤞🏼

I work with teams of developers that are mainly experienced in Typescript, and having the ability to give them a back-end that they can easily extend, that generates sane GraphQL endpoints, and provides a simple-to-learn UI that we can share with non-technical stakeholders has been a game-changer.

With this said, I'm worried that the Payload CMS team feels like having delivered a stable and mature solution (which is true) but might be forgetting to address technical debts and community pain points in favor of focusing on shiny new features.

I write this with the highest of respect for what the team has achieved, and just looking to share some of my experience in similar projects.

My experience: users/clients are currently happy, but there's also unresolved issues and discussions. Adding new features will no doubt add technical debt (on top of the existing), and this is like a pressure pot, there's only so many pain points a user community will quietly endure, and the moment the pressure pot blows, the project is already past the point of no return.

With that said, I have the following pain points it would be lovely that the Payload team address before thinking of future directions:

• Next.js is SLOW for development purposes
  • Since we work with multiple Payload driven projects, we're constantly starting and stopping Payload locally, and having to wait 10+ seconds for initial compile really adds up in lost development time, before on Payload v2 we didn't notice any slowdowns, but Payload v3 has really affected productivity
• Next.js is also quite slow in regards to performance
  • on Payload v2 we had circumvented this by drop-in replacing Express with Fastify, but after months of trying in v3, we have yet to find a way to do this with Next.js
• Next.js caching is a pain (both compiled code caching as well as ssr/browser caching), don't know what else to add to this since this is a known pain point of Next.js which they refuse to address
• Next.js routing is really badly abstracted and architected
  • with v2 we quickly made a plugin that could dynamically serve all REST API routes as an UI using swagger, but Next.js obscures routing so much that there's no easy way to get this working the way we did before Swagger and OpenAPI plugins #2432 (reply in thread)
  • also the amount of headaches we get from 'use client' vs 'use server' vs having forgotten to add either of them and having the app work fine one minute, then breaking the next, have been plenty
• Next.js cannot play nice with sockets
  • before on Payload v2 we had a server.ts file that would spin up socket.js for us, but Next.js literally recommends spinning up socket.js separately and having the Next.js server be a privileged client of the socket.js server 🤯
• There's many gaps in Payload CMS' documentation that make it hard for many teams to adopt Payload seamlessly:
  • for example, it's already happened in 3 separate projects that types stop being generated because someone placed an import of a component on payload config rather than a string of the path to the component
  • in my case I address this by having my own documentation filling these gaps for my teams, but this is less than ideal
  • better custom GraphQL query/mutation documentation would be ideal, we already implemented multi-create and multi-delete for Payload v2 and were disheartened to see v3 breaking this functionality for us as we were even planning to publish a plugin but has now been postponed until we have the time to circle back and fix these custom GraphQL mutations
• Payload's handling of db relationships should really be improved, once a project using Paylod CMS matures to the point of complex DB relationships, development slows down due to having to write custom code to address the lack of Payload CMS standardized relationships

I do have a wish list of features I'd like to see on Payload CMS that are present on other headless CMS solutions, but I'd rather hold off on those in hopes that the above pain-points are addressed (or fixed, ideally) sooner than later.

Thank for the awesome work Payload CMS team, you're delivering really useful functionality for countless dev teams worldwide 👐🏼

Really looking forward to see continued success for this project 🚀