
Relax – A New Generation CMS on Top of React, Redux, and GraphQL - nikolay
http://getrelax.io/
======
lojack
IMO, you're giving way too much control to the end user with regard to
configuring the layout and minute details of their page. Giving a content
author control over the padding, background, font choices, etc, is a recipe
for them creating super specific pages that look bad and have no consistency.

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.

~~~
andybak
I completely agree.

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.

~~~
wslh
> The reason we've developed our own CMS framework (on top of Django)

Is it open source? How does it compare to Mezzanine CMS?

------
djsumdog
One thing that's really missing from the OSS world is a CMS that builds static
content. We've got Jekyll, Hugo, Middleman and others that are really only
targeted at developers.

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).

~~~
mapgrep
No, this is a terrible idea that is being spread like a cancer by people who
don't know their history.

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.

~~~
gizzlon
Is speed really an issue today though? With multiple cores, multiple machines
etc.. Seems like a simple enough engineering problem. How many "pages" does a
big site have? How many can be touched by a single update?

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.

~~~
mapgrep
Well there's the small answer and the big answer.

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.

~~~
awinder
But from that storage "problem" you get to avoid hosting on a dynamic
platform, and literally just need a static web host. As mentioned you can put
stuff up on s3 and be done with it.

At large scale of visitors, this kind of approach is a lot easier to handle
than the dynamic model.

------
therealmarv
Speaking with my DevOps hat I cannot "relax" with MongoDB in the backend ;)
Have you done ANY heavy loadtesting with this infrastructure (which is cool
but does it scale?) and what is your result in comparison to Wordpress and
static content?

How likely is it possible to switch to another database like PostgreSQL?

~~~
weddpros
Considering most CMS systems barely reach 100req/s (uncached), I think we can
say raw database speed is less of a problem than bad query patterns. Or if you
prefer, the use of a SQL db is no guarantee for performance.

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...

~~~
therealmarv
100% agree. But there is not a single word about caching or how to integrate
it with Relax either. I understand it is a young project but if I need a CMS I
want it to have it a little tested and scaling questions not open. Caching is
totally NOT trivial with React,Redux,GraphQL (at least I totally don't know
how to do it but maybe I'm not smart enough) ... maybe it is even harder with
such an architecture. I'm just saying I doubt a littlebit the cool and shiny
architecture justifies the purpose (many questions open).

~~~
bruno12mota
Hey! Relax creator here. Thanks for your input :)

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...](https://blog.michaelckennedy.net/2010/04/29/mongodb-vs-sql-
server-2008-performance-showdown/)

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/](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 :)

------
nikolay
Source code: [https://github.com/relax/relax](https://github.com/relax/relax)
Demo: [http://demo.getrelax.io/admin](http://demo.getrelax.io/admin)
(username: demo, password: demo)

~~~
dexwiz
Doesn't work for me.

Works now, was getting 403

~~~
TuringTest
It doesn't work on Firefox (using the Developer Edition, may be related to
that).

~~~
wigginus
Doesn't work in the 'classic' edition either.

------
degenerate
I don't have one specific piece of advice, but after playing with the demo,
the front-end of this CMS is very hard to use. I don't seem to know what the
heck is going on when I create new items or drag little boxes around. I
literally have no idea what I am doing.

~~~
bruno12mota
Hey! Relax creator here. Sorry to ear that. Since it's a demo people add a lot
of noise to it (a lot of styles and colors etc), with a private account and
with some theme imported you'd see that making a theme is a bliss with it :-)

We're also redesigning the admin entirely for the beta release
[https://twitter.com/relaxjs/status/699674354657976320](https://twitter.com/relaxjs/status/699674354657976320)

------
einrealist
I wish, someone would build an OSS CMS on top of Apache Sling. The concepts of
JCR and Sling are perfect up to a point, where I don't want to deal with
anything else. If my company had the money, we would instantly buy Adobe AEM
licenses. Unfortunately its soooo expensive and they are the only ones who
have a CMS frontend for Sling.

------
kelvin0
I've just started working with Joomla in the last few days. The only redeeming
factor with it is that you can install it anywhere (since PHP is so
prevalent). I wanted to install Django-CMS, but guess what: the host I have to
work with does not support Python... So I'm stuck in CMS Land with choices
that don't really help me much. Hopefully I'll get over the initial 'ugliness'
in using Joomla. Relax CMS requires Node.js, which unfortunately is also not
supported as much as PHP ... _sigh_

~~~
matt4077
If Joomla today is similar to Joomla ca. 2010, I'd rather call each potential
visitor and read them the html than use that CMS.

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.

------
dcsan
Is there an easily accessible API for this? The ability to add schemas, and
manage media is nicely done, but for a game app I'm building we have our own
client app. I'd like to mix the occasional embedded webview, but mostly just
access content as JSON. There maybe other CMS tools that are more suited to
being used just for their backend, any reco's appreciated ^_^

~~~
bruno12mota
Hey! Relax creator here. Schemas you create in Relax will be able to mark as
publicly accessible, so you'll be able to use it as an API, it's a GraphQL API
though :)

------
j1436go
Throwing "Uncaught TypeError: Cannot read property '_currentElement' of null"
on the page edit view. UA: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36. Just saying ...

------
amcleod
Interesting idea and I can see this being really useful. Question: Is it
possible for developers to extend the base component set with new components?

~~~
bruno12mota
Hey! Relax creator here. Yes it will. You'll be able to create any component
to use on the page builder where you can make your own settings and styles
options.

------
fallenshell
TIL: Add the words React and Redux to something and it is immediately cool.

~~~
mixedCase
"We've now switched away the human interface used to manage the control rods
in the nuclear reactor from antiquated buttons and levers to a touchscreen
running an application powered by node.js+React+Redux"

:^)

------
Sir_Cmpwn
Dependencies: Chrome

Come on guys, test your software properly.

~~~
kylemathews
It's in alpha.

"Relax isn't yet ready for production, stay tuned for releases, beta version
will come soon"

------
chrisabrams
Where are the tests!???????????

