Relax – A New Generation CMS on Top of React, Redux, and GraphQL
getrelax.io
getrelax.io
Typically, I'll limit clients to specific widgets and layouts and train them on how and when to use these elements for maximum effect. That's the only way to maintain design integrity. I don't let them pick fonts, font sizes, colors, etc. Authors are given a list of choices for the fonts, and these choices correspond to the font hierarchy specified early on, and they have to build pages within those bounds.
The idea is you want to give them just enough control to author the content they need (without weird hacks) and nothing more.
This is also true of rich text editors (at least in their usual default configurations. First thing to do is hide most of the options)
The reason we've developed our own CMS framework (on top of Django) is because everything else I looked at had a complex, powerful and dangerously flexible interface. I lock down almost everything apart from content fields and a choice of page types (about us, contact, product lister etc).
A CMS isn't a design tool or a page layout package. Unless you're building something that's meant to be reusable and configurable by end-users (a mammoth and complex task which you probably want to avoid) then lock down as much as possible. I've had more problems from allowing too much flexibility than i ever get from allowing too little.
Is it open source? How does it compare to Mezzanine CMS?
We'll also have a templates feature which users can use to not start a page from scratch :-)
I'll admit, it's not easy. This is why CQ, Teamsite, et. al. cost a lot of money (insane amounts of money, oh and they're both terrible. CQ is good for end users, terrible for devs. Teamsite is just terrible, and cost $11k per website).
[1]: http://prose.io/#
First of all, static rendering CMS-es are IN NO WAY missing as you say; in fact, as your own comment hints, such systems are incredibly abundant. There are MANY other static-render-HTML products that could be added to that list, and they stretch back into the 1990s.
The basic problem with this approach is well understood: As the corpus of content on a given site grows, render time quickly approaches time between updates. In other words, you start waiting for renders to complete before you can change something else on the site.
This happens in part because changes to a single particular piece of content often cause changes to multiple pages — think blog views, archive pages, index pages, tag pages, RSS feeds. Meanwhile, as a site grows, the number of contributors tends to grow, including authors, editors, illustrators, photographers. So not only are the static renders taking longer as the site grows, there is also a growing likelihood that someone will want to touch a piece of content in a given time period, thus triggering a new render.
Probably the most high-profile example of how this could fail was when there were a lot of people using Movable Type for their blogs in the early 2000s; MT did static renders and many bigger blogs had switch to other blog engines or carefully operate around massive render times for MT sites.
If you have a small personal site, static renders are fine. But SO IS BASICALLY EVERYTHING ELSE. You can build a personal site using any number of primitive-but-effective technologies, like server side includes, emacs macros — hell you could literally make a Microsoft Word template and publish everything from there via SFTP. On the flipside, you could install the most inefficient, computationally intensive, database driven crapfest of a web app and it won't matter because you don't need to scale.
In other words, static CMSes are fine if you don't actually really need a CMS. By all means, for yourself, or a tiny project, use whatever you want. But we don't need MORE of those tools.
There are a huge number of websites (ie: like every small business website I have ever been to) that have like 5-10 pages tops and they almost never change. For all intents and purposes, they are static. Throwing such sites up on github or s3 is a no brainer. I disagree with your statement that we don't need MORE of those tools. We absolutely need more of those tools, but not for developers (there are literally a million to choose from if you are a developer), what we need are nice clean user-friendly front ends. Every time I have to enable javascript just to visit some Wix website I cringe a little.
I would actually say, though I vastly prefer say Jekyll over WordPress, that generating a static site from a WordPress site probably works pretty well and gets you a very mature CMS UI for your users.
Doing it that way round is probably preferable and better understood at this point than the newer solutions that are trying to bolt CMS backends onto Jekyll sites (CodeCannon, Prose.io etc).
In any case, for the websites I am talking about (small non-technical businesses in particular), wordpress is overkill and operates at a higher layer of abstraction then necessary. Also, such a solution has almost all the disadvantages of wordpress (Finding wordpress hosting [These guys are not going to have their own on-premise wordpress install], setting up and configuring wordpress, keeping wordpress and plugins up-to-date), for very little advantage (slightly more consistent load times? ). Just putting a CDN in front of it would get you most of the way there.
It's also hard to recommend a good wordpress host [The exception to this is sandstorm, which is amazing and does the wordpress->static thing exactly right]. Managed wordpress is what you want, but it's bloody expensive (again, IMO, but these kinds of customers are generally cheap). Anything more hands-on than fully manged hosting is a lot of work and maintenance for something these people are realistically NOT going to use on a daily basis.
I think Wix and Squarespace serve a very much needed part of the market, and I wish I could point people at an elegant open source solution that would allow "normal" people to have affordable websites backed by S3 or Github pages (like us developers enjoy).
Is this limit still likely (honest question)? Hugo seems to benchmark at around 1ms/page.
What sort of scale is common for large sites, what speed would need to be hit for this to become a problem that's simply irrelevant at even the largest scales?
Also see Hugo, as someone mentioned..
Not doubting that you're right regardign the history, just that it has to be this way today. OTOH, a dynamic page can also be plenty fast, it does not have to be Wordpress.
The small answer is that rendering touches not just CPU but storage as well. Yes we have SSDs, which help, but writing to "disk" is still relatively slow.
The big answer is: If you can render each of your pages very quickly, there's no real win from pre-rendering everything. You should just render on the fly. The whole point of pre-rendering, historically at least, is to make a site very fast by eating the cost of the render up front.
At large scale of visitors, this kind of approach is a lot easier to handle than the dynamic model.
This way few or no pages need to change just because the shard content (e.g. a "latest posts" box) changes when a new post is added.
And you still get the speed of serving, security, AND simplicity and easy hostability of merely serving static files.
Only on naive systems -- or if you change the design and layout of the whole site.
Besides, for 99% of websites that are not news or forum sites, the content never grows that much. And for brochure style sites, it's at most a few 10s of pages per year.
>Meanwhile, as a site grows, the number of contributors tends to grow, including authors, editors, illustrators, photographers.
That never happens for 99% of sites -- that could still use static rendering.
So not only are the static renders taking longer as the site grows, there is also a growing likelihood that someone will want to touch a piece of content in a given time period, thus triggering a new render.
>On the flipside, you could install the most inefficient, computationally intensive, database driven crapfest of a web app and it won't matter because you don't need to scale.
It's not just about scale.
A sort of CMS-like frontend to Hakyll (the Haskell Jekyll). I've tried to more or less sketch out the idea here https://github.com/Tehnix/hakyll-frontend.
It made some really novel decisions on the Admin UI spectrum, and it's not terrible for content managers as a lot of open source CMS software tends to be, but it never gained traction. My familiarity with Perl isn't what it should be, so it's always painful to try to dig in to debug problems as well.
How likely is it possible to switch to another database like PostgreSQL?
Maybe mongodb will perform better, free of joins, than MySQL/Wordpress/whateverCMS... or maybe the data access pattern will suck and make it slow (and maybe it would be slow with a SQL db too, like other CMSs).
Ideally (in terms of performance), a single K/V request would be needed for each page, and the CMS would handle all the denormalization (and tens of thousands of req/s). I don't know how they've designed their data model...
All in all, a CMS is the most cachable web app ever, as it's more or less meant to replace static pages ;-) The poor performance of existing CMSs has always been hidden by caching layers...
Saying PostgreSQL is a better fit in terms of performance is a bit controversial in my opinion, there are quite a lot of tests between the two and most say it is the exact opposite https://blog.michaelckennedy.net/2010/04/29/mongodb-vs-sql-s...
Despite that, can't say for a fact that's the case for Relax since I haven't test both on it. Mongo is behaving really well though, our demo instance has been getting a pound lately (dozens of users at a time) and it's running smoothly even though our machine is not really powerful.
Also in terms of scaling, Mongo also has a great solution for horizontal scaling https://docs.mongodb.org/manual/sharding/
Having this said, not entirely against having different database layers supported in Relax. Since we're using GraphQL would be a matter of creating an abstraction when accessing the data on the queries and mutations resolves. Not on our priorities for now but we're always open for contributions :)
Works now, was getting 403
We're also redesigning the admin entirely for the beta release https://twitter.com/relaxjs/status/699674354657976320
I'm really quite fond of the static generators now. I'm not even sure why – the principle isn't much different from a dynamic CMS with caching. And data probably belongs in a DB rather than a bunch of files. But the architecture of Hugo etc. make them really easy to understand, I can host it on google cloud storage (and probably serve thousands simultaneously without breaking a sweat), it's as fast & save as possible and I don't have to worry about passenger/postgress/memcached/etc. making any trouble.
I'm sure the next step will be web-based authoring tools for Hugo/Jekyll/etc., which will seem a little strange but actually get us close to the best of both worlds.
Disclaimer: I'm on the bolt.cm team.
:^)
Come on guys, test your software properly.
"Relax isn't yet ready for production, stay tuned for releases, beta version will come soon"