[HN Gopher] Launch HN: Payload (YC S22) - Headless CMS for Devel...
___________________________________________________________________
Launch HN: Payload (YC S22) - Headless CMS for Developers
Hey HN, my name is James and I founded Payload
(https://payloadcms.com/) with two close colleagues, Dan and
Elliot. We're a dev-first headless CMS [1] that's half app
framework and half CMS--we're closing the gap between the two. You
can check out our demo here: https://demo.payloadcms.com. Imagine
you're going to build a new SaaS app. Would you think of building
it on a headless CMS? Probably not. To devs, "content management
system" is usually a swear word. If a team of engineers gets
assigned a CMS project, it's less than thrilling. Engineers want to
avoid roadblocks, write code, and build things they're proud of--
but existing CMS's get in the way of that left and right with their
third-party integrations, point-and-click schema designers, code
generation, etc. Rather, you'd build your backend on an app
framework like Django, Laravel, etc., for good reasons: ownership
over the backend, better access control, customizable auth
patterns, etc. Typically, headless CMS are super limiting; you'll
end up fighting the platform more than having it help. But, with
app frameworks, you're often left to roll your own admin UI, and
that takes time. Not to mention building CRUD UI gets old quick
after you do it a few times. That's where a headless CMS could
shine, because they instantly give you admin UI that non-technical
teams can use to manage digital products. That saves a ton of UI
dev time-- but without an extensible API, headless CMS's are far
too limiting. They're designed for marketing teams, which usually
only need the generic basics: log in, create a draft, preview the
draft, publish the content. Go back and update some pages. Define
editor roles and localize content. If you need more than that,
you'll soon be out of luck. Payload is different because we treat
developers as first-class citizens. We provide the best of both
ends: a powerful and extensible API and a fully customizable admin
UI out-of-the-box. All with a developer experience that we obsess
over, because we want it ourselves. Payload is code-first, which
allows us to get a lot of things right. We give you what you need,
then step back and let you build what you want in TypeScript.
You'll understand how your CMS works because you will have written
it exactly how you want it. Version control your schema and use
your own Express server. Completely control the Admin panel by
using your own React components. Swap out fields or even entire
views with ease. Use your data however and wherever you need thanks
to auto-generated, yet fully extensible REST, GraphQL, and Local
Node APIs. Since it uses your own Express server, you can open up
your own endpoints alongside what Payload does. In fact, you can
extend just about everything that Payload does. It's MIT and open-
source, fully self-hosted, comes with GraphQL and REST APIs, and
completely customizable. We realized the need for Payload while we
were building the corporate website for Klarna. The Klarna
engineers we were working with were among the best in the world,
and while they evaluated headless CMS options, they saw
restrictions in how all of the normal contenders "black-box" away
the API. They wanted to build their CMS, deploy it on their own
infrastructure, and truly "own" their CMS. They fell back to using
WordPress. When that happened, Klarna inadvertently shined a
spotlight on the CMS market and pointed out a significant void in
proper code-based, developer-first CMS. There was no one to give
them the developer experience they needed. That's what got us
started working on this. It might seem like a CMS is just a
wrapper around a database with a nice UI to show different field
types--but in reality, it's a lot more complex than that. We
obsessed for years around how to build a proper API that minimizes
breaking changes, but still exposes a simple way to extend
everything. When you start to introduce things like field-based
access control, field-based conditional logic, localization,
versions, drafts, and autosave, the task becomes a lot more
daunting. Doing it right requires a significant development
investment--especially if you want it to perform at scale in
addition to removing roadblocks at dev time. It seems like every
day, a new headless CMS pops up. But when you filter down to those
that are completely self-hosted, the options quickly dwindle. And
then when you remove the confused point-and-click "no-code" (argh!)
GUI nature of the existing options, the options narrow to one:
Payload. Our users have built quite a diverse set of apps on
Payload. We've seen a virtual events platform, a broadcast
platform, SaaS apps of all shapes and sizes, video games, and an
Uber-like snow plow service! There are over 1,000 projects in
production as of last week, and we can't wait to see more. Open
source has been incredibly helpful. We've gotten significant PRs
and our community has gone above and beyond in their contributions.
We did not anticipate the level of skill and involvement that we
are seeing daily from our community. Our business model is based
on two things: 1. Enterprise features like SSO, audit logs,
publication workflows, and translation workflows. Of course, as
Payload is open-source, you can build these functions yourself, but
enterprises are opting to pay for our official functionality and
SLAs rather than rolling it themselves. 2. Cloud hosting. Now that
Payload 1.0 is released and ready for production after more than
two years of development and dogfooding, we've shifted focus to
building a deployment platform for Payload that will deliver
permanent file storage, database, API layer, and CI. It will be the
easiest way to deploy Payload, but not mandatory to use--much like
the NextJS and Vercel model. You can get started in one line by
running `npx create-payload-app` or you can try out our public demo
at https://demo.payloadcms.com. The code for the demo is at
https://github.com/payloadcms/public-demo. We would love to hear
your feedback. If we don't have something, we'll build it. If
there's a sticky spot in the DX (developer experience), we'll fix
it. Looking forward to hearing what you think--and thank you! [1]
Quick refresher: CMS stands for "content management system" and
headless just means API-based, with no restrictions over where you
use the content on the frontend.
Author : sneek_
Score : 136 points
Date : 2022-08-31 17:14 UTC (5 hours ago)
| jppope wrote:
| Looks great. Lots of little "nice to have"s all over the place,
| and the latency is pretty snappy. Not the way I'm interested in
| doing my content these days but I can see the appeal for sure.
|
| good job
| sneek_ wrote:
| Thank you! Yep, the fact that we ate our own dogfood for over a
| year really helped us fill in the "nice to haves" all over the
| place.
|
| How do you do your content nowadays? Git-based CMS? Markdown?
| Would love to know!
| brycelarkin wrote:
| This looks great! We use Strapi for our marketing site at
| https://articleasset.com and have been bitten by the lack of
| conditional logic before.
|
| Is there any plan to support serverless deployment? We use Nextjs
| with incremental static regeneration, so will only need to query
| the cms service a couple times a day.
| jobsdone wrote:
| 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.
| brycelarkin wrote:
| Understandable. Appreciate that you all have a monetization
| strategy already. One of my hesitations with adopting VC-
| backed open source projects is that a lot of them don't have
| a clear business model.
|
| We host Strapi on a server, so shouldn't be a problem.
| xenni wrote:
| Depending on the startup time, you can use something like AWS
| Serverless Express and just wrap the application. If startup
| takes a little while you can store an instance above the
| handler code which will be kept alive across invocations of
| that serverless instance.
|
| I've used this to great success in a similar project.
| arraypad wrote:
| As someone who's been actively looking for a headless CMS
| recently, I'm curious about how you compare yourselves to
| Contentful [1]?
|
| From a quick look the key difference is that Payload's backend
| can be self-hosted, but Contentful is SaaS only.
|
| You've said that you're targeting enterprise customers and
| mention an SLA in that respect. Does that mean your enterprise
| offering is also SaaS only?
|
| [1] https://www.contentful.com/
| sneek_ wrote:
| Hey there - your points are accurate! Here are a few more:
|
| - We are open source / MIT
|
| - You can re-use Payload's auth layer in your own apps and with
| Contentful you can't
|
| - Contentful has rigid RBAC, but Payload features function-
| based access control down to the field level
|
| - Payload supports field conditional logic, meaning "check a
| checkbox, see more fields, uncheck it, extra fields disappear".
| This is huge. And is super hard to build right but it's very
| important for a good admin experience.
|
| - Payload gives you a local Node API (note: not HTTP / REST /
| GraphQL.) Contentful does not. With Payload's local API, you
| can do lots of awesome things within hooks, access control,
| etc. - and even reuse it in your own endpoints. All of this is
| impossible with Contentful without going through their HTTP
| layer
|
| - Payload lets you add your own admin UI views
|
| - Payload has no usage limits
|
| - Payload is code-first, Contentful is "point and click"
|
| Phew. There's a lot more. This all is just top-of-mind word
| vomit.
|
| Our enterprise offering can either be self-hosted or it can
| leverage Payload Cloud, once we have it built. Some enterprises
| opt to manage Payload on their own infrastructure, and just pay
| us for SLA and premium features like SSO, audit logs, etc. But
| we do have enterprises in line to use our managed
| infrastructure as well... so basically, the answer is "both".
|
| Does that help answer your questions?
| arraypad wrote:
| That is all useful info, thanks.
|
| For the enterprise offering can you give a rough idea of
| pricing without having to book a demo etc.?
| sneek_ wrote:
| Yep! As our cloud hosting is not yet launched, we don't
| have the pricing finalized for that but for our enterprise
| features and SLAs, it's all broken down based on what you
| need. For 20 seats, a few enterprise features and a lower-
| tier SLA, you'd pay a few thousand a month.
|
| For hundreds of seats, with a more robust SLA, your costs
| would scale linearly, but it's entirely based on what you
| need.
|
| Does that help?
| robertlagrant wrote:
| In my previous job we struggled to get a CMS for our app: it was
| a medical app with articles embedded in it, and we wanted a way
| to have doctors and translators work independently in a CMS
| environment, with the final product being released in the normal
| way.
|
| We never found anything that would have done the CI automation we
| wanted, or not without significant customisation. Do you support
| CI workflows at all?
| sneek_ wrote:
| Just about anything CI-wise you can think of is completely
| doable with Payload. That's the beauty of being staunchly code-
| first.
|
| I would love to hear more about this at some point too, btw.
| imjonse wrote:
| Nice. A page comparing this with existing solutions would be
| useful. In particular how does it compare to something like
| Wagtail which is a CMS but also has all of Django to fall back on
| for custom backend work.
| sneek_ wrote:
| Hey there - we do have a set of comparisons on our site (linked
| in the footer of the site), but we don't have a comparison to
| Wagtail yet. Would be happy to add this to the list!
| lnxg33k1 wrote:
| I see the value in this product, and I agree that for developers
| it's boring to build CMS, that's why me and my team have been
| shopping around for a solution to give marketers and sales a tool
| which could give them autonomy, we picked contentful a couple of
| weeks ago as no one wanted to be on call for hosting issues, so
| it's a shame, I wished you could've launched few weeks ago but
| now we've already started developing it after pitching it to
| stakeholders and getting the budget approved, good luck for your
| success
| sneek_ wrote:
| Awww dang! Sorry to have missed you. I've used Contentful in a
| handful of projects in the past and our team's struggles were
| partially responsible for the creation of Payload. Keep us in
| mind for your next project - and best of luck!
| mrwww wrote:
| Looks great! I've been looking to avoid rolling my own admin for
| my hobby project, which is mongo based, and very much driven on
| certain db schemas and collections. Adding CRUD and simple admin
| views to the mongodb will go a really long way, and the flex to
| throw in some react sounds great. Glad i found this!
| denolfe wrote:
| Awesome, sounds like the perfect fit for your project!
| emrah wrote:
| Congratulations!
|
| > To devs, "content management system" is usually a swear word.
|
| Yet "CMS" is in your tag line. Is that not a bad idea then?
| sneek_ wrote:
| I lolled at this - gonna cause me to do some introspection,
| huh.
|
| One goal of ours is to make this not the case - but you are
| 100% right. The whole notion of "app framework / headless CMS"
| doesn't have a good label so right now we've gotta make some
| concessions. We have this discussion quite often!
| billyhoffman wrote:
| Nice job getting to launch. However I'm really confused about the
| value prop.
|
| > There's no point competing in that noisy market, so we're
| undercutting it instead, by treating developers as first-class
| citizens.
|
| Who is the target market for this? who are the users and what is
| the job function in their company?
|
| The vast majority of CMS use is by Marketing departments building
| the public web presence of their company. Marketing doesn't care
| about building or maintaining their own CMS, or making it easy
| for developers. In fact, those are costs they want to minimize
| and externalize.
|
| Speed of creating, editing, reviewing, and publishing content is
| the most important thing. Integrating the site into the hundreds
| of mar-tech tools is also important (e.g. gating content for
| sales leads, funnel analytics, mailing list signup and
| validation, A/B testing, etc)
|
| Large CMSs are pretty optimized for the create-review-publish
| flow, and I don't see you explain any advantage you provide here.
| Mar-tech companies live or die on adoption, so they invest
| heavily in making plugins for CMSs. Something they are not going
| to do for Payload. Why would marketing pay for internal
| developers to do this integration (regardless of how easy it is)
| when they get that for free with plugins to existing systems,
| written by the engineers of those systems?
|
| In short, none of the benefits you cite at all align with the
| KPIs of a marketing department using a CMS (typical engagement
| numbers like time-on-site or page views, but also marketing-
| generated or marketing-influenced leads and opportunities)
|
| And as an engineer who has built multiple SaaS apps, I've never
| needed CMS capabilities built into those apps. The closest need
| would be the help/documentation/API spec, which we've
| traditionally addressed using another site or SaaS app (e.g. a
| third party helpdesk or knowledge base SaaS).
|
| Hence why I'm a little confused, but do want to be positive. Who
| is your ideal customer, why, what business problems do they have,
| and why is Payload the best option to those problems?
| culiao wrote:
| Agreed! Do you have a favorite CMS?
| dang wrote:
| (offtopic side note in case anyone is confused: I edited out
| that line you quoted. launching these guys was a last-minute
| thing this morning so I've been editing their blurb on the fly,
| from airplane wifi no less. I hope it worked!)
|
| (this does not affect your question)
| tootie wrote:
| This guy CMSes.
|
| I worked in consulting for many years doing a lot of CMS
| projects for Fortune 500s. They always bought their CMS
| products based on the marketing pitch to marketers. It was
| mostly bs, but the pitch was always focussed on engagement,
| testing, analytics, funnels, acquisition. I always came with
| the perspective that your CMS need not and usually should not
| be responsible for any of that and you can manage all of that
| in the application tier via a tag manager product or the like.
| The current kind of this space is Adobe. They built up their
| "Marketing Cloud" vis a series of acquisitions and sell it as a
| fully-baked product that does everything you'd ever need and
| then attach an 8-figure price tag and hand you off to
| integrators (like the companies I worked for) to do the (also
| very costly) implementation. And it's really very hit and miss
| to get adoption after you've delivered them such an ornery
| beast to manage 30 pages of brocureware.
|
| We managed to push a few clients towards Contentful which is
| headless and a lot more dev friendly but they also are pretty
| sneaky with pricing and get fairly expensive with anything
| beyond basic usage. I actually begged their sales team to do a
| better job selling to marketers because their pitch was too
| tech focussed. I think the sweet spot is to not just say
| "developers like it" but rather "it will require far fewer
| developer hours to implement" which will resonate a lot more
| with budget holders. Also, my firm belief that building a suite
| of marketing tools by picking and mixing the best products is
| likely still easier and cheaper than buying any all-in-one tool
| that isn't great at anything.
| sneek_ wrote:
| I resonate a lot with what you're saying.
|
| > I always came with the perspective that your CMS need not
| and usually should not be responsible for any of that and you
| can manage all of that in the application tier via a tag
| manager product or the like
|
| Totally agreed. A CMS should stick to managing content. And
| its flexibility should allow it to integrate with services
| that are purpose-built. In addition to those that you
| mentioned, a good example of this would be Algolia for search
| experiences.
|
| > "it will require far fewer developer hours to implement"
| which will resonate a lot more with budget holders.
|
| I also resonate with this, and I think this needs to be
| worked into our positioning more, because that, at its core,
| is what Payload tries to do -through- its developer
| friendliness. When you don't have to fight your software, you
| save an incredible amount of time. At the core of any larger
| content infrastructure is code, and the more efficiently you
| can implement it, let alone maintain it, the more time /
| money you can save.
| sneek_ wrote:
| Hey, great question. Our target market is enterprise uses of
| Payload, where we can power critical content-based
| infrastructure, but that does not solely mean marketing
| websites.
|
| I think that your comment is pointing at one of the areas that
| traditional CMS -do not successfully address- in that CMS is
| typically only thought of as a means to manage website content.
| But content is much more broad. Think of Spotify (managing
| album art, playlists, artist descriptions) but using that
| content through native apps, smart TV apps, web apps, etc.
|
| For example, some of our current enterprise clients are using
| Payload to deliver _their_ clients with a customized copy of
| Payload to manage their own virtual events (attendees, webinar
| links, landing page content, post-webinar video recordings,
| etc). Or to manage a "broadcast platform" where their client
| can publish their own Roku channel (episodes, series, seasons,
| playlists, etc). This is all content, yet it's not marketing
| page content.
|
| One of the bigger uses of Payload so far has actually been to
| power the entire backend for an Uber-like snow plow service,
| where the business side can log in and provide customer
| support, manage requests, approve service providers, and more.
| The devs were able to leverage Payload's auth, access control,
| hooks for Stripe integration, and last but not least - the
| entirety of its admin UI.
|
| That's not to say that we -can't- power marketing websites. Of
| course Payload can do that in spades. But that is only one
| small aspect of our target market and we make the most sense
| for enterprise content needs, where dev teams may need to
| manage more than just marketing pages. Maybe they also need to
| manage customer support resources or more intense content needs
| (like Klarna).
|
| In my experience implementing enterprise websites for large
| companies, the buying process usually goes like this:
|
| - Director or VP of Marketing says we need to modernize and
| move to a better web stack, let's go headless
|
| - They start to evaluate options, but need engineering backup
| because headless CMS is a tech decision
|
| - They tell their engineering team to go find the best headless
| CMS
|
| - Devs do the recon, then report upward
|
| Our strategy is to appeal straight to devs, and by being a
| solid product that they can advocate for, they will. This is
| actually how Klarna found my agency when we were hired to build
| their enterprise site - by the engineers. Decision to go
| headless came from the top, but then engineers found me and
| selected tech. Same with a few of Payload's bigger inbound
| enterprise opportunities in the pipeline right now.
|
| Long story short, I fully understand your question and in all
| reality our messaging is nowhere near sharp / completed. We've
| seen a lot of growth over the past few months and are about to
| the point where we can take a breath, revisit some of this, and
| razor-sharpen our positioning!
| iamnatch wrote:
| Hi James,
|
| I'm really excited about V1 release of Payload, as well as the
| open sourcing of the project. I've wanted to use it in a project
| for a while and this news is definitely going to push me over the
| edge. I'm a huge fan of the typescript first approach, as well as
| local mode, and the thought that went into adding custom blocks
| and components.
| sneek_ wrote:
| Ahh thank you! You cherry-picked my favorite parts about
| Payload. So much went into having a proper custom block-based
| field type. That in specific is something that every single
| project I build has always needed and this is only the start.
| We have a lot of ideas that are going to take our blocks field
| to the next level.
| idleproc wrote:
| Looking forward to a replacement for https://www.netlifycms.org/
| sneek_ wrote:
| Yeah! We've had a lot of people move to Payload from Netlify
| CMS. Those that have moved have given us a ton of great
| feedback in regards to our UX and dev experience comparatively.
| mwcampbell wrote:
| > Imagine you're going to build a new SaaS app. Would you think
| of building it on a headless CMS?
|
| I'm guessing this mostly makes sense for a SaaS that's mostly
| about serving content to users. I wonder how common that kind of
| SaaS is, as opposed to a SaaS where the core functionality
| wouldn't be served well by a CMS, and the administrative tedium
| that one wants to alleviate mostly has to do with account
| management, payment processing, enabling or disabling service
| based on billing status, etc.
| jobsdone wrote:
| 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.
| Eric_WVGG wrote:
| 1. Outstanding marketing site.
|
| 2. My initial thought was, "this looks fantastic... just as good
| as Sanity, which is a problem because Sanity is already around so
| what's the point? Really my only gripe with Sanity is that
| there's no free open sou--" oh dang, there it is.
|
| Yeah, I will definitely give your product a shot on my next
| project.
| sneek_ wrote:
| Yeah! The other big difference with Sanity is that the API side
| of Sanity is 3rd-party. So you never truly have control over
| the API logic or backend side at all. Whereas with Payload, you
| control both the admin UI AND the entirety of your API. That's
| what I mean by "closing the gap" between an app framework and a
| headless CMS. Lots more backend potential with Payload.
| matejlauko wrote:
| It looks awesome, I will give it a try.
|
| There's a loot of CMSs already, but the quality open-source ones
| is usually.. lacking. A high quality one with great DX has a huge
| potential
| sneek_ wrote:
| Thank you! I totally agree. I've been using headless CMS since
| the start and have ridden along with a few of the options out
| there, but never trusted them enough to hit production.
| esilverman wrote:
| Really impressive, congrats on the launch!
| sneek_ wrote:
| Thank you! We're looking forward to doubling down our efforts.
| So much more to come.
| iLoveOncall wrote:
| I know that a lot of web frameworks already have admin panels
| available either released by the main development team or by a
| 3rd party. What is the advantage of using Payload over those?
| jobsdone wrote:
| 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?
| denolfe wrote:
| Elliot from Payload here. In addition to Dan's comments above,
| the main advantage of using Payload's Admin is that it can
| integrate directly with your auth as well as offer a richer
| editing experience beyond the normal CRUD that others provide.
|
| For instance:
|
| - Field-based access control - This allows a developer to use
| code to write complex functions in order to regular access to a
| field. This can also reference the currently logged in user's
| permissions/fields etc.
|
| - Conditional logic - Functions can be written to show/hide
| certain fields in the admin UI
|
| - Dynamic field types - Complex layouts can be built with the
| Block and Array field types. This allows the ability to build
| out more of a "page builder" type input vs. simple CRUD.
|
| I hope that answers your question. Here are some links to the
| docs on each of those:
|
| - https://payloadcms.com/docs/access-control/overview
|
| - https://payloadcms.com/docs/fields/overview#conditional-
| logi...
|
| - https://payloadcms.com/docs/fields/blocks
| WaitWaitWha wrote:
| Congrats on the launch.
|
| What is the difference between this, and say a customized
| vBulletin _et al._? (or, did I misunderstand what the offer is?)
| sneek_ wrote:
| Well, at its core, Payload is a headless CMS / application
| framework. There are actually quite a few differences between
| either of those and a forum software like vBulletin which is
| deliberately geared toward creating online communities
| (moderation, comments, threads, etc.)
|
| Payload could power the same use cases as something like
| vBulletin, but its use cases are significantly more widely
| applicable because Payload is not geared solely toward being
| community software. Instead, Payload delivers a content API and
| admin UI to power / manage just about any type of digital
| product you can think of, ranging from enterprise marketing
| websites, to native apps, to omni-channel content (think
| Spotify music), to SaaS app backends, to video games. Of
| course, forums are included here.
|
| Does that help clarify?
| paxys wrote:
| Great site and product. How will you monetize this? An obvious
| way is to offer a hosted version of the product on a subscription
| basis, but that doesn't seem to be possible in this case
| considering the whole value prop is to embed this in your own
| server.
| sneek_ wrote:
| In my original post, I've outlined our monetization strategy at
| a high level. And cloud hosting is certainly an aspect of our
| approach.
|
| It's true that some will self-host Payload, and that's awesome.
| But look at NextJS - you can self-host NextJS as well, but most
| people go to Vercel. Hosting a CMS is quite a bit more
| complicated than a static site or a set of serverless
| functions, because you need to have a database and permanent
| file storage as well. Payload will provide all of that out of
| the box with a one-click Git integration.
|
| Our users thus far have been telling us that they struggle with
| cobbling together vendors and wish that this was easier, so
| we're building Payload Cloud as a result.
|
| One other aspect of Payload Cloud is that even though we
| -provision- the infrastructure for you, you'll always have
| access to it. You'll be able to connect to your DB, back it up,
| export it, etc. This is all in the works now!
| raajg wrote:
| Similar to https://pocketbase.io ?
| sneek_ wrote:
| Yep, but with a lot more admin-specific features like field
| conditional logic, block-based layout editors, customizable
| React components, localization, versions / diffs / drafts /
| preview / autosave, etc. Payload ships with way more than just
| a CRUD UI!
| junwonapp wrote:
| I love it. Congrats for launching!
| chrisweekly wrote:
| Great writeup; bookmarked, will revisit soon.
| jph wrote:
| Congratulations and great idea! What's your roadmap or appetite
| for pay-for-features? For example, what would be involved in
| hiring your team to improve a specific area or two?
| sneek_ wrote:
| This is _hugely_ important to us. For features that belong in
| the core, we point people to GitHub Discussions
| (https://github.com/payloadcms/payload/discussions) and more
| often than not, we are pretty fast to green light / build
| certain features for free. Our community has also been straight
| up amazing in this regard.
|
| But if you've got something more significant that you'd like a
| hand with, we'd be happy to chat. Sounds great!
| simonhamp wrote:
| Congrats on the launch! Great to see more forward-thinking CMS
| solutions hitting the market.
|
| We've been using Statamic[1] (built on Laravel) which is also a
| package that's sits atop the framework so you can build your app
| how you like and side-load CMS features.
|
| It also features an API. The whole platform is steadily improving
| despite being a small bootstrapped team behind it.
|
| If you're looking for something like Payload but for Laravel,
| give Statamic a go!
|
| [1]: https://statamic.com
| jobsdone wrote:
| I've heard good things about statamic also. How do you feel
| about their pricing model?
| colesantiago wrote:
| This is welcome, great launch James.
|
| I'm constantly looking about for a new CMS system, either Strapi,
| Wordpress, etc, how does PayloadCMS compare to these?
|
| What is PayloadCMS's killer feature?
| sneek_ wrote:
| Thank you!
|
| WP is a blogging platform from the early 2000's that still uses
| many of the same code conventions that it started with. It does
| have a REST API, and you can extend it with plugins to work as
| a headless CMS, but it's riddled with inefficiencies and is
| truly a great example of why most devs would not think to reach
| for a CMS if they were building a SaaS app. Can you build a
| SaaS app with WP? Sure. Should you? Absolutely not. WP is good
| for its plugins and themes, but for anything more robust, it
| falls apart.
|
| Strapi is a contender that is quite similar to Payload but they
| have a mixed focus on "GUI-based" logic and code-based logic.
| You design your content models with a GUI, and access control
| is highly limited to a typical RBAC pattern. Where in Payload,
| everything -starts with code-. You can version control your
| schema, because it's all just a config. Deploy to other
| environments (stage, prod, etc) with ease. Use and re-use
| functions across different collections. Even access control is
| handled beautifully with functions in Payload, and is
| significantly more powerful than RBAC.
|
| I'd say our killer feature though is the simplicity, yet
| robustness of our admin UI. We have many features that Strapi
| does not have - like field conditional logic (Check a checkbox
| field, see more fields. Uncheck checkbox, those fields go
| away). Our admin UI is also completely extensible. You can
| create custom field types easily just by importing React
| components and passing them to a field config - then boom, your
| React component appears in the admin UI rather than the built-
| in component. It's intensely powerful.
|
| There's a lot more, but these are just a few quick points. I've
| been using headless WP for ~6 years, and I've always liked the
| idea of Strapi, but never trusted it enough to hit production.
| That's why we built Payload.
| Narretz wrote:
| What you describe sounds similar to Statamic. The config and
| even the content is yaml files, and the admin UI is also
| quite extensible. But I always wish it was easier to change
| stuff with code in Statamic, so maybe that's where Payload
| shines.
| sneek_ wrote:
| Nailed it.
|
| Payload's config is straight up TypeScript. Import a React
| component, pass it to your config, and boom -- it shows up
| in your admin UI.
|
| Everything is written like that and this is certainly where
| we shine!
| [deleted]
| zmz88 wrote:
| Looks like an interesting idea. Other than PHP-hate, why would
| someone choose this over something like Drupal?
| sneek_ wrote:
| Drupal is obviously one of the longest-running content
| management systems available and they have done a much better
| job at keeping up with the moving target that is tech, when
| compared to Joomla / WP.
|
| Outside of being written in TypeScript with more modern
| conventions, the fact that Payload borders on an application
| framework is what would make someone choose it over something
| like Drupal.
|
| Feature-wise, this commonly means reusing Payload's auth in
| your own app(s), defining function-based access control rather
| than RBAC, swapping in React components into the admin UI, and
| more.
|
| But another HUGE reason is that when we built Payload, we tried
| to keep its own internal conventions as close as possible to
| just regular JS / TS. If you know JS, you know Payload. With
| Drupal and even WP to an extent, you need to know how _their_
| conventions work. It's all very specific to the platform and
| the Payload team has always hated that. Devs don't want to
| learn CMS - they want to learn the underlying language, and
| Payload embraces that to its core.
| solardev wrote:
| Personal opinion: Even as someone who used and loved PHP for a
| decade, Drupal is just awful. It's overengineered and bloated
| and the documentation is pretty sparse, not to mention it's
| hard to scale up. Its admin and editor UX is decades being
| modern headless CMSes. It is extremely powerful, but seemingly
| built to handle the most extreme edge cases rather than the
| most common use cases, and a lot of the power is just confusing
| and unnecessary for your typical website. In like 10% of the
| time it takes to get a Drupal system up and running well, you
| can do the same thing with Wordpress and Advanced Custom Forms
| and end up with an infinitely better UX, DX, and EX.
|
| Drupal suffers tremendously from "by engineers, for engineers"
| and it's just an incredibly poor experience if you don't fit
| that mold. It's non-stop pain for no reward.
|
| Having used it for a major project (both in daily use and in a
| big migration from D7 to D8/9), I will NEVER take another job
| that uses Drupal again... it is the second most dreaded web
| framework for a reason (above only Angular):
| https://survey.stackoverflow.co/2022/#section-most-loved-dre...
|
| Halfway through our Drupal "upgrade" (rewrite, because D7 had
| no upgrade path), we just gave up on it and went to Next.js + a
| headless CMS instead. Everyone was massively happier after
| that... the devs, the editors, IT, marketing, content writers,
| analytics... Drupal was just soooo bad that even its newest
| version was years if not decades behind modern experiences.
|
| Sorry I feel so strongly about this... the mere word makes my
| blood boil. I've never _HATED_ a technology the way I hate
| Drupal, before or since. If you 're considering it for a
| project for the first time, don't walk, SPRINT as far away as
| it as you possibly could.
| jobsdone wrote:
| 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.
| tehno wrote:
| You should try to get listed on awesome-cms [1] list now too,
| since you're out with public release. That was the first place I
| checked for options last time I needed to find a headless CMS.
|
| [1] https://github.com/postlight/awesome-cms
| jobsdone wrote:
| Absolutely! Thanks for linking this.
| onelovetwo wrote:
| Was a complete turned off by the original monetization model,
| what has changed?
| sneek_ wrote:
| Sharp eye - we threw it away and went MIT a few months ago!
| Basically.... we listened to our audience. And it was a great
| move. So, thank you for giving us the push if you commented or
| provided feedback in any way!
| onelovetwo wrote:
| That's great to hear!
| sneek_ wrote:
| Seriously, it's liberating to -say-. We're so happy with
| the move. Credit to the community.
| brown wrote:
| Congrats! So much opportunity for an API-first CMS.
| s_severus wrote:
| Hi James, congratulations on the launch!
|
| The website looks great, your pitch is compelling and the vision
| is very similar to what I've been doing with vendure.io, which
| takes the same approach but towards ecommerce rather than CMS.
| Namely: open-source, headless, Node/TypeScript, dev- and code-
| first.
|
| In our experience, your thesis is correct in that there certainly
| is a niche for a great, dev-first, self hosted version of what is
| otherwise seemingly already handled by SaaS products. We see
| users moving to Vendure from closed SaaS commerce platforms for
| reasons like: full control over the code & data, integration
| requirements, need to support unique requirements, wanting to
| build their own platform etc.
|
| Furthermore our business model is similar - MIT core and paid
| enterprise plugins, and exploring cloud. Notably enterprise
| support and SLAs is also becoming a major area for us.
|
| So it's great to see a kindred product getting some attention
| here on HN!
|
| If you are interested to swap insights or discuss potential
| collaboration (many of our users are looking for a good CMS...)
| feel free to drop me a message at m.bromley at vendure.io :)
| sneek_ wrote:
| Ah awesome! Thanks for the comment! I'd absolutely like to
| trade experiences sometime. I will certainly send you a
| message.
|
| Looking forward to it!
| vikasnair wrote:
| We have a Next.js website with a blog section that's powered by
| Sanity. Problem is, it's pretty finicky to install basic
| components that we like to use (which looks like Payload comes
| with out of the box) + communicating with Sanity via groq is
| clunky with Typescript (and possibly causing some SEO issues).
|
| How simple is it to install Payload in an existing Next.js app to
| power basically just the /blog/* subdirectory?
| sneek_ wrote:
| Insanely simple. You can opt-in on a page by page basis with
| NextJS to any data source that you want to use. I LOVE NextJS'
| paradigms, and we've actually modeled a lot of what we do after
| its beautiful DX.
|
| Great question!
| jobsdone wrote:
| 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.
| KaoruAoiShiho wrote:
| I just evaluated all the javascript headless CMS just last week
| and my conclusion is that the best offering in this space is
| probably directus. Maybe I'll do a writeup when my directus app
| gets up and running.
| sneek_ wrote:
| Yeah - Directus certainly provides a lot of value out of the
| box. We're a bit more razor-focused on a code-first approach
| vs. Directus, as the content model is stored directly in the
| database rather than being defined in a version-controlled
| schema. And in Payload it's much easier to swap in your own
| React components / customize the admin UI. But we really
| respect the Directus team for sure!
| TheMiddleMan wrote:
| This is great, I can stop emailing markdown files back and forth
| with my content writers.
|
| Would this work as a sort-of wiki, for crowd-sourced
| documentation and translations? Or is it a bad idea to let the
| public edit things?
| sneek_ wrote:
| You can absolutely do this. You can bake in any type of
| "review" workflow you can think of, and Payload comes with
| versions / drafts out of the box as well. It's easy to control
| who can update the "main" published doc, vs. who can submit
| drafts.
|
| Would love to see if you gave this a shot, and we'd be happy to
| help along the way on Discord!
| TheMiddleMan wrote:
| Wonderful! What a great product, well done. Thanks.
___________________________________________________________________
(page generated 2022-08-31 23:00 UTC)