A CMS is something teams spend a lot of time in. And it's worth it to pay a little more for a great user experience. We spent a lot of time focusing on the user experience.
There are a lot of free or cheaper CMS options out there with a not great user experience.
Most of the modern frontend hosting services also push for a backend as a service. Whether it be a DBaaS, like Fauna https://www.fauna.com, or Headless CMS, like Cosmic https://www.cosmicjs.com as it gives you the auto-scaling capabilities without the infrastructure time and headache (Disclaimer: I'm CEO at Cosmic)
Hi I'm Tony, CEO of Cosmic (W19). Cosmic is a Headless CMS that provides a web dashboard to create content and API tools to deliver content to any website or app. We just released the Cosmic REST API v2 which we rebuilt from the ground up.
Check out the link above to see the changelog article or you can read the list of improvements / features / changes here:
New Features:
Nested metadata props are now possible without limit. This gives you GraphQL-like data response powers to get only the data you need.
No depth limit for Object relationships. The only limit is the prevention of infinite recursion.
We now offer a Postman collection to review and demo all REST API methods. This is a great way to get started with the new API methods.
You can now use the after param for Object pagination vs limit and skip.
We now have endpoints for Metafields and Media Folders to do CRUD operations directly.
Improvements:
Lighter codebase, faster endpoints. In some cases, endpoint response times are up to 50% faster (non-cached).
Better endpoint structures that follow standard REST conventions such as POST /resources, GET /resources/:resource_id, etc.
Consistent error responses with verbose messages.
The Select Dropdown Metafield now includes both key and value in the API response.
Changes:
_id has been changed to id.
type_slug has been changed to type.
status can now either be published or any (which returns latest Object version draft or published).
query is now the primary method for fetching and filtering Objects (Advanced Queries from v1).
Single Objects must now be fetched using id. To fetch by slug, you will need to use query.
write_key will now be required in the request header as Authorization Bearer.
metafields are hidden by default.
Stricter user input requirements. No additional fields are possible in the body for POST and PATCH requests.
There is a new, more secure token authentication strategy.
Hi HN! I'm Tony, CEO and cofounder of Cosmic (YC W19). Since launching our headless CMS on HN during our YC batch (https://news.ycombinator.com/item?id=19330262), we've been working toward finding better solutions to content management problems.
Something we've noticed is that traditional CMS systems have long relied on a draft/published model for content updates within a single database. For many use cases this is fine, but many of our users want to create multiple environments to stage updates for review, preview the changes, then push the changes to production. There wasn't an easy way to merge content changes between environments in review stages (such as Development, Staging, Production). This is especially true when you want to make large bulk edits to lots of content.
For this reason, we built Merge Requests. Much like software teams use Git to work in branches, make pull requests, and so on, this lets our users work in isolated content environments to add/update content, safely isolated from production. When ready, a merge request is submitted to review content changes. Reviewers can be added to review and approve updated content. Preview links are available to preview bulk edits in the user-facing application or website. After approvals, a merge is performed. If needed, restoring to a previous version can be done in a few clicks.
The feature is free to anyone with an account, but if you want to see how it works without signing up (we know you, HN!), check out the screenshot videos on the blog announcement (linked at the top). To go deeper, sign up for a free account (https://www.cosmicjs.com/). You can also install the Next Merge Starter (https://github.com/cosmicjs/next-merge) which includes merge request preview capabilities. Read the docs to get more information on how to implement the merge request preview for your applications currently available via the REST API and NPM module (https://docs.cosmicjs.com/rest-api/objects.html#get-objects-...).
This is work in progress and we would greatly appreciate any feedback that you may have in the comments below!
This changelog announcement is a big one for us and includes:
Upgraded infrastructure
New Metafields and
Optimizations to our open source clients.
1. Infrastructure Upgrade
We're happy to tell you that all Cosmic JS components are now powered 100% by serverless technologies. By running completely even-driven using AWS Lambda functions, the REST API, GraphQL API, Dashboard application, and the website are now infinitely scalable through high traffic loads.
This is huge, because it means you can depend on us to deliver your content through the highest traffic loads with dynamic server capacity on demand. This is also big for the Cosmic JS team, because we are now able to make product improvements at a higher velocity with a more streamlined deployment process.
We have also added a caching service to our website to serve our website resources at the edge. Your team can now get to any resource on cosmicjs.com faster and easier with at least 10x faster page loading from any spot on the globe.
Thank you. These are all great questions and things we consider a lot.
> How will you pitch this moving further up-market? Especially where the opex exists that dev costs are less important. And vendor lock-in (or likelihood of existing in five years) becomes an issue?
We believe that developer experience is table stakes now. It's becoming less the case that the CIO buys the tech and hands it to the development team. Developers are more and more making these technology decisions for their organizations. So it's our goal to empower the developers to help champion Cosmic for their team.
> And further up the enterprise scale, the greater the demand for a robust open source community. Is this on your roadmap?
Absolutely, that's why we're continuing to offer open source example apps, extensions, and integrations that can power complex business logic and to satisfy these types of customers.
> Any plans to ramp up the devrel?
Definitely, it's a big priority of ours to stay active in the developer community to listen and respond to use cases, technologies, extensions, and integrations that our customers will find valuable. This is our David / Goliath strategy. When you don't have a war chest to spend on marketing and sales people, you have to be resourceful :)
> And.. wat will CosmisJS look like in two and five years?
We've got an ambitious roadmap, so stay tuned! Simply put, our north star is to provide the most value for our customers by being the best solution in the era of API-first services.
1. We do offer a full data export. After you login, go to Bucket Settings > Import / Export to get a full JSON file export of your Bucket.
2. Thanks for the feedback. Anything specific?
3. Early on we wanted to be able to add dynamic content to any website server-side or client-side using NPM / React / Angular. And the domain name was available :)
4. Our target customer is teams, not individuals. And the value resonates even more with larger teams because they experience more of the pain. We've actually been told they would pay more :)