[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 : 228 points
Date : 2022-08-31 17:14 UTC (1 days 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?
| swyx wrote:
| for what its worth - would take this "word vomit" and polish
| it up and post it somewhere. Coherence does a great job of
| this: https://docs.withcoherence.com/docs/coherence-vs-other-
| softw...
|
| most people wont read it, but the serious people will. and
| better to claim your narrative than leave it in the hands of
| users who know less than you about your own market.
| 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?
| jwhiles wrote:
| I'm kind of curious what you mean by 'point and click' here?
| The contentful web interface is, of course, a web interface -
| but it's perfectly possible to interact with the API directly
| for people who want to do so.
| 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.
| spdustin wrote:
| > Consistent with Payload's goal of making you learn as little of
| Payload as possible, customizing and using the Rich Text Editor
| does not involve learning how to develop for a Payload rich text
| editor. Instead, you can invest your time and effort into
| learning Slate, an open-source tool that will allow you to apply
| your learnings elsewhere as well.
|
| I have to say, this callout from the JSON-based Rich Text Field
| docs [0] really resonated with me. Rather than build out
| something yourself that would further lock folks into your
| platform (and force them to customize yet another bespoke tool),
| you leaned on an existing, mature, and capable framework for rich
| text editors, Slate [1]. And your stated reason--to "allow you to
| apply your learnings elsewhere as well"--was really appreciated.
| It shows a lot of respect for time and resources of the
| individuals using Payload.
|
| I don't have a specific need for a headless CMS right this
| second, but I can promise that Payload will be my first candidate
| to review when I do. Previously, it would've been Strapi, as I've
| used that tool already for several projects. But that one
| paragraph _really_ struck me.
|
| [0]: https://payloadcms.com/docs/fields/rich-text [1]:
| https://docs.slatejs.org/
| sneek_ wrote:
| Ugh I am so happy that this paragraph resonated with you. I
| personally wrote it and it's so, so important to me. It
| represents the ethos of what we're trying to do with Payload.
| The whole team and I feel very strongly about this.
|
| Thank you for your kind words and I would love to help you as
| you start your next project with Payload!
| 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.
| ThibWeb wrote:
| I'd be really interested in this as well (disc. - I work on
| Wagtail). This feels so similar to our vision for the CMS aside
| for the fact the project has been running for a while and is in
| Python land.
| 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!
| edem wrote:
| As a developer I'd never use this. I don't want to learn the
| thought process of someone else just to get some work done, I can
| do it myself. If I want a headless CMS there are plenty of
| options out there.
| 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!
| jimnotgym wrote:
| I surveyed the headless cms market a couple of years ago and I
| found some good platforms but the pricing just didn't work. I
| would much rather run our own like this. Good move, and goodluck
| sneek_ wrote:
| Thank you! I agree!
| 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.
| Dwolb wrote:
| Inbound developer interest = company intent (and segment
| intent).
|
| Just make sure your growth motion doesn't stop there and
| layers in a way to nab the buyer.
|
| Standard way is to outright ask for introduction or
| outbound, but there's usually a clever referral mechanism
| you can discover somewhere.
|
| e.g. "Ask your marketer for demo content" prompt, but with
| better copy.
| sneek_ wrote:
| 100%.
|
| This is very good insight and I will take it to heart.
| 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.
| rezonant wrote:
| February 37nd, 2022? [1] When did they add so many more days in
| February?
|
| [1] https://payloadcms.com/
| sneek_ wrote:
| Ha actually that is a mockup and I personally wrote that in in
| there to give peoples' brains a blue screen :)
|
| Sort of an easter egg. I also worked in a bunch of references
| to Metal Gear Solid (so good) elsewhere in our screenshots as
| well. This is likely going to all be removed though as I really
| wouldn't want people to think this is a Payload bug!
| statictype wrote:
| I assume they are using date-fns - Saw this bug in that lib
| once when doing a demo and it was really embarrassing. You
| would expect a date processing library to somehow manage to not
| have bugs like this.
| jobsdone wrote:
| Haha, you called it!
|
| I guess we'll have to update those screenshots! :)
| 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.
| endymion1818 wrote:
| Congrats @sneek_ and team, looking forward to sparring with you
| some more!
| 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.
| swyx wrote:
| any chance the website itself is open source? i'd love to see
| how Payload uses Payload.
| sneek_ wrote:
| Not yet. When we built the site, Payload's licensing and
| business model was built around a SaaS model, and was all
| baked into Payload's frontend. Of course, it does use
| Payload on the backend (including the entirety of our old
| SaaS billing infra) but for those reasons, we did not open-
| source it.
|
| However, v2 is coming and that will 100% be open-source!
| adrianthedev wrote:
| Guys, amazing work you're doing with Payload. I think it's
| pushing the way we build apps forward. I love the energy, but you
| should communicate more sincerely. In your intro video you say
| "frameworks like Laravel and Rails can be great on building the
| back-end of your complex apps, but then you're stuck having to
| build the entirety of your admin panel completely by yourself",
| and that's untrue. There are solutions out there that help you
| not build it by yourself.
|
| Again, great energy, but don't lie!
| jobsdone wrote:
| 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?
| chimen wrote:
| 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.
| sneek_ wrote:
| 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.
| uzername wrote:
| Congrats on the launch. I saw payload here on HN a few months
| ago. Good seeing it again.
|
| On the "Enterprise" sso approach, are your first party offerings
| just plugins? I've worked with various node cms recently, and for
| our needs we often see the only way to extend is by dangerously
| forking the upstream rather than hooking in through the plugin
| architecture.
|
| The second aspect I wondered about, is why Mongo? It doesn't seem
| as "open" compared to a postgres, although maybe works better for
| your hosting platform offering. I wonder if an adapter to pg/json
| might be possible.
|
| Thanks, and good luck with launch!
| sneek_ wrote:
| Thank you!
|
| Yes, all of our first-party offerings are plugins and 100% of
| their functionality can be accomplished with Payload core
| itself. No need to fork or extend. Our plugin infrastructure
| runs incredibly deep and it's super straightforward.
|
| Mongo was extremely deliberate. The nature of "content",
| especially pages and posts, lends itself extremely well to the
| document-based structure of NoSQL. Add in complex field types
| like arrays, a block-based layout builder, groups, and more,
| and this becomes even more apparent. But this all being said,
| supporting Postgres is on our radar and will be happening at
| some point. Our internal infrastructure is already quite
| organized and swapping out a different database adapter won't
| be a monumental task. It'll require some work, for sure, but
| it's doable.
|
| Thank you for the great questions!
| sgammon wrote:
| Nit, but, "The most powerful TypeScript headless CMS there is."
|
| Should be
|
| "The most powerful headless CMS for TypeScript"
|
| Or something to that effect. The first time I read the headline,
| I thought "there is" was preparing for a followup sentence.
| sneek_ wrote:
| Fair enough. That whole headline needs to be rewritten IMO.
| Describing Payload in one sentence is super tricky and feels
| like buzzword soup.
|
| We're on it. Actually I think the whole site needs to be redone
| but I'm never happy with my own work.
| 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?
| graphememes wrote:
| I think that we do need more CMS. However, I was really put off
| by the homepage. It's very hard to figure out what really
| differentiates you from others, the interface is very hard to go
| through with all of the scrolling left / right. Based on the
| responses here it seems open source?
| sneek_ wrote:
| Thanks for the feedback! Our website has changed minimally
| since launch. In about a month or so, our focus will be
| shifting back toward sharpening our messaging and presence
| online.
|
| Yes--as you mentioned, Payload is self-hosted, open-source,
| natively TypeScript and extremely extensible both on the API
| and admin UI sides. Outside of specific features that we
| support and others do not, those are the big differentiators.
| But there are lots more!
| 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!
| sgammon wrote:
| Currently working on some SaaS, so I'd like to take a look at
| this and see if it fits.
|
| Curious if there are multi-tenancy features baked in, since you
| mentioned targeting SaaS companies? Really happy to see all the
| recent innovation in this space, congrats on the launch :)
| sgammon wrote:
| For example, can the cloud version do sub-tenants? Is the admin
| panel exposable to end-users? That sort of thing
| sneek_ wrote:
| Yes! You can absolutely do both sub-tenant / multi-tenant
| architecture and you can definitely expose the admin panel to
| end-users.
|
| Both are possible. Thank you for your kind words!
| sgammon wrote:
| One more question: is support for non-node environments on
| the way? We use a bit of node but we're mostly JVM. Kotlin
| would be clutch, all good if it's not yet in the cards.
| mxstbr wrote:
| How does this compare to KeystoneJS, another TypeScript CMS?
| https://keystonejs.com/
| cjonas wrote:
| I've been using keystone to run a small coffee roasting
| operation. The underlying concept (primsa + graphql + custom
| crud hooks + ootb ui) makes it incredible easily to model and
| build businesses processes.
|
| Only compliant is that the admin UI isn't that flexible or
| extendable. You eventually end up rewriting standard views
| entirely when you need to add additional features that ideally
| would have just been minor extensions (eg adding a custom
| action to a record page)
| 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.
| sneek_ wrote:
| Thank you! We would love to help support you in your first
| Payload project if you need a hand. We're super active on
| Discord. Stop by if you need anything!
| 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]
| chimen wrote:
| Congrats on the launch. Always wanted something like this to be
| able to build a more opinionated CMS on top of it for all my
| projects. My first try was Qards (https://www.qards.io/) but the
| npm, exhaustingly breaking changes from js libraries + the
| painful experience I've had dealing with & integrating Netlify
| CMS into it just left me dry by the time I've actually launched.
| Was a cool project though and I'm thinking of reviving it one
| day, maybe with Payload.
| sneek_ wrote:
| Oh I can intrinsically relate to what you're saying. I would
| love to see your project revived on Payload. If you need a
| hand, please do reach out on Discord!
| 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.
| porker wrote:
| > I've never HATED a technology the way I hate Drupal, before
| or since.
|
| Did you ever work with Magento 1? :)
| solardev wrote:
| Lol, we briefly evaluated it and noped outta there quick as
| we could... phew, bullet dodged :)
| 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.
| cies wrote:
| Few things I really need in a CMS:
|
| * allow me to create a localized content (you seem to have this
| covered).
|
| * a good story for blobs (images, video, PDFs, etc).
|
| * integrated full text search (I do not want to set up elastic
| search when using a headless CMS saas).
|
| * 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).
|
| * 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).
|
| * 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.
| jobsdone wrote:
| 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.
| jobsdone wrote:
| 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.
| lucas_codes wrote:
| Have you ever found one that covers all of these well?
| cies wrote:
| Nope. Not even close. And always a huuuuuge hassle to work
| around a missing bit when needed (obviously we can also
| change the requirements to meet deadline/budget)
| 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.
| 5Qn8mNbc2FNCiVV wrote:
| Question: How are migrations handled? Can I rename fields without
| losing my data? Can I change a relation without losing the
| underlying data? Are there other edgecases where I lose my data?
| sneek_ wrote:
| Thanks to using MongoDB as a database layer, you will not lose
| your data if you rename fields. This is a huge benefit for
| NoSQL in general honestly and it is one of the reasons why we
| chose to move forward with Mongo initially. We will be
| supporting Postgres + others in the future, at which point we
| will be introducing a migrations pattern, but for now, you
| don't need to worry about that at all.
|
| With Payload as it stands now, to migrate data from one field
| to another, you can make use of Payload's Local Node API to
| move data from one property to another with ease.
| brown wrote:
| Congrats! So much opportunity for an API-first CMS.
| rolisz wrote:
| Honestly, this sounds more like something like Chiselstrike than
| a traditional CMS
| sneek_ wrote:
| Yeah! That is, Chiselstrike with a purpose-built admin UI that
| accompanies your backend. That's a big one-up for Payload.
| 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-09-01 23:02 UTC)