Relax – A New Generation CMS on Top of React, Redux, and GraphQL

http://getrelax.io/

by nikolay • 10 years ago

149 58 10 years ago

getrelax.io

nikolay• 10 years ago

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

dexwiz• 10 years ago

Doesn't work for me.

Works now, was getting 403

TuringTest• 10 years ago

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

lojack• 10 years ago

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• 10 years ago

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• 10 years ago

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

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

bruno12mota8• 10 years ago

Hey! Relax creator here. You're absolutely right, although Relax stays in between that problem. Each component can have styles, and these styles will come alongside a theme. Which means if the end user is using a theme, he'll just have to drag and drop components, and select the style from the ones the theme has. Makes sense?

We'll also have a templates feature which users can use to not start a page from scratch :-)

conceit• 10 years ago

isn't that for template authors?

Sir_Cmpwn• 10 years ago

Dependencies: Chrome

Come on guys, test your software properly.

untog• 10 years ago

Good news: it's open source! Maybe you can test it on Firefox and give you feedback in a Github issue?

kylemathews• 10 years ago

It's in alpha.

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

bruno12mota8• 10 years ago

Hey! Relax creator here. Actually the demo version goes back quite a while. We're redesigning a refactoring pretty much of it. Should be completed soon and we'll update the demo when it's more stable :-)

j1436go• 10 years ago

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

degenerate• 10 years ago

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.

bruno12mota8• 10 years ago

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

djsumdog• 10 years ago

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

antimatter• 10 years ago

Perhaps this might be what you're looking for? https://www.getlektor.com

therealmarv3• 10 years ago

+1 for lektor. But a cool bootstrap theme on top and you get anything you need like good categorization and pagination etc.

jgillich• 10 years ago

Prose[1] makes editing static sites quite easy. Unfortunately, the last time I tried it, it had lots of bugs and missing features, but seeing that there's been quite a lot of activity recently that might have changed.

[1] http://prose.io/#

asteadman4• 10 years ago

This is either much better than it was last time I saw it, or i've missed it entirely. Thank you!

mapgrep2• 10 years ago

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.

asteadman4• 10 years ago

I don't think anyone is claiming that a static CMS would be a "good idea" for people who have a multitude of pages that are constantly changing, that is of course, madness.

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.

IanCal• 10 years ago

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.

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?

biot• 10 years ago

How large does a site need to be before render time becomes a significant issue? I can understand it being an issue for, say, Google News or some other highly dynamic site where the input sources are programmatic. But for sites where there are humans providing the content, why in today's computing era would it take more than a minute to update hundreds of pages?

gizzlon• 10 years ago

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.

coldtea2• 10 years ago

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

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.

giaour• 10 years ago

You're assuming that a site's traffic and content change rate grow at the same (or similar) rates. This is almost always true of media properties, but not necessarily of popular single-contributor blogs or brochureware for business, organizations, political campaigns, etc. Many of those are powered by WordPress or Drupal, but they could exist as static sites, as their traffic level is not correlated with their rate of change.

owenwil• 10 years ago

That actually exists. A bunch of friends at Cloud Cannon built a front-end layer for Jekyll and it works really well: http://cloudcannon.com

Tehnix• 10 years ago

I think you just gave me my new side/hobby project :)

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.

tootie• 10 years ago

Teamsite costs way more than $11K. $100K at least. If you but their whole platform, it'll be closer to $500K

hmartiniano• 10 years ago

Lektor (https://www.getlektor.com/) might be a good candidate for that. It has a graphical user interface which makes editing accessible for non technical folks.

chrisparsons• 10 years ago

Bricolage in the late noughties was this. Salon ran it for a fair amount of time. The company I work for currently uses it, although I think we're one of the last ones, and since it's not really getting any updates anymore, we'll likely be moving off of it in the near future.

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.

einrealist• 10 years ago

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.

amcleod• 10 years ago

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?

bruno12mota8• 10 years ago

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.

therealmarv3• 10 years ago

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• 10 years ago

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

therealmarv3• 10 years ago

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

fallenshell• 10 years ago

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

mixedCase• 10 years ago

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

:^)

bruno12mota8• 10 years ago

There's a reason to it :)

kelvin0• 10 years ago

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• 10 years ago

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.

SahAssar2• 10 years ago

I've found bolt.cm very nice to work with. Joomla is basically the most frustrating CMS experience I've had.

Disclaimer: I'm on the bolt.cm team.

bruno12mota8• 10 years ago

There's always some dependencies. Most hosting companies nowadays have servers setups that already brings you Node.js installed the same way you have servers with PHP configured. You just have to think PHP is declining and JavaScript rocket flying so things will turn on this. Also with docker setup on the way for relax, it'll be a breeze

chrisabrams• 10 years ago

Where are the tests!???????????

dcsan• 10 years ago

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 ^_^

SahAssar2• 10 years ago

Bolt.cm seems like it would fit your usecase. Just use one of the JSON extensions for it for the JSON output.

bruno12mota8• 10 years ago

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

Relax – A New Generation CMS on Top of React, Redux, and GraphQL

Related Stories