Relax – A CMS on Top of React and Node.js | Hacker News Reader

Relax – A CMS on Top of React and Node.js

github.com

128 pointshliyan62 comments

I don't understand why (seemingly) every CMS wants to get involved in the request serving process.

I'd really like to see CMSes which only do content management, then expose that content via very simple JSON APIs. Then I build the website myself separately as a super lightweight HTML rendering service which pulls from the CMS API.

Every CMS I've ever used didn't scale because its templating/rendering/request stack was so heavy.

Agreed. Not least because you're more than likely going to want to pull CMS data into an existing site, or push it into Solr/elasticsearch, or customise the site in ways the CMS authors haven't allowed for.

I think I'd be more tempted to adopt a CMS library than a CMS framework.

I'm having a hard time visualizing what this CMS data would be like or how it would be any different than just having it in Solr/elasticsearch/couchdb to begin with.. Can you or someone else provide me examples of how it would work?

I'm not quite sure what he meant, but it is common to push data from a CMS to a search engine. Note that most "real" CMSs have a built-in search engine, so the data is pushed automatically. Most seem to use Lucene/SOLR or Elasticsearch.

Why not put it in the search engine to start with? So the editors can edit the content. And the search engine is rarely the master of the data.

I believe they're referring to something like this: http://getcockpit.com/

There are CMSs that can expose the content via a simple API.

Another important distinction between CMSs are those provide full templating system (Wordpress etc) and those that control the request, but don't put any restrictions on how the html is generated. You use standard .net/java/javascript to generate the template based on data from the CMS. Two completely different approaches.

You might want to check out teletext.io, it just launched a couple of days ago.

I liked the look of this initially, and thought it was well presented, but personally I don't like the idea of all layout being dynamically generated on the client side. Taking your static layout as an example, you can see the browser needing to make a second request for the data the first time you load it.

https://teletext.io/static-example.html

You can also use the API directly from your backend instead of using the javascript client, but that will eliminate some of the cool things we can do now like the inline-editing feature for content editors.

I don't see how one should exclude the other. I really liked your demo of inline editing. But there's nothing to stop you updating the data asynchronously like that, while also allowing the page to be rendered server side as well.

Wordpress (yes I know) has a pretty robust JSON API plugin[1], which is being rolled into core as of the next release (4.4). This means it's dead easy to have a familiar CMS experience and then pull out the data in whatever way you want.

There are plugins available for other CMSs[2] which do pretty much the same thing too.

[1]: http://v2.wp-api.org [2]: https://github.com/pixelandtonic/ElementAPI

We have been using wordpress as a cms with their xmlrpc api since at least 2010. Works great and is easily extensible using hooks.

Front end written in java.

You are still dependent on XML-RPC, which has its own overhead issues, and PHP/Wordpress though.

I don't think this is what the OP is advocating since a major caveat with the Wordpress API plugin is that you are still tightly coupled to PHP and Wordpress. This is simply due to the poorly designed database schema and how Wordpress "renders" posts. I can't simply use Wordpress as a generic CMS, as post data is still dependent on Wordpress to render.

Unless I'm misunderstanding something, it's not rendering any views, it's returning queried data. I guess you could call the JSON a rendered view if you wanted to.

Are you concerned about being coupled to the particular shape of the returned JSON? That seems valid to me, especially if you're not very fond of the schema.

I wouldn't advocate for WP for anyone continually developing an evolving product, but for small business clients it's not bad. It's easy to use and familiar, which goes a long way.

I disagree with the notion that the WordPress REST API plugin is "robust." Having developed on it several times, it really doesn't live up to the standard set by great APIs and has a lot of missing components.

Having a great JSON API baked into the core and dogfooded for the admin UI should really be a focus for WordPress.

The JSON API is getting baked into the next core release, and dogfooding it is (afaik) on the medium-term cards.

Have you tried version 2? Personally I found it substantially easier to work with than v1.

> The JSON API is getting baked into the next core release, and dogfooding it is (afaik) on the medium-term cards.

Awesome, that's great to hear.

> Have you tried version 2?

I've actually worked with both versions. v2 is nicer but also didn't support some required functionality at all.

Prismic (http://prismic.io) follows this concept, no rendering just an API + backend.

The extremely flexible API of ProcessWire (no template engine here, just pure PHP in a JQuery inpsired API [1] ) lets you expose parts or whole of your website structure as JSON REST services (or XML, or plain text, or RSS, or what want you).

As a bonus, the it also makes writing simple pure-php "templates" (yea, its not really templates, but) super easy. You basically just drop in your HTML/CSS/JS stuff, and add a few pw api lines here and there, and you're done.

In my experience after 8 years of Drupal experience, and 1 year of ProcessWire experience, is that PW is what Drupal should have been from the start: Elegant, Lightweight, Fast, and Flexible. I'm sold!

[1.a] http://cheatsheet.processwire.com

[1.b] https://processwire.com/api

ProcessWire's design is peerlessly elegant. It doesn't try so hard to get in your way when you know what you want to achieve. I wish there were more CMS like that.

But in my experience, it's not fast: even with caching enabled, every request took >250ms. I don't want to rely on Varnish for reasonable latency. Did I do something wrong?

I didn't test it, but this module should be better than the default caching solution: https://github.com/trk/AvbFastCache

Indeed.

Drupal 8 does exactly this. Use Drupal 8 for data modeling and storing the data. Use its forms if you want to. Retrieve the data using GraphQL and do all the rendering yourself. It even is capable of a hybrid model, where it serves pages BigPipe-style, and you do client-side rendering for the most dynamic/interactive parts.

See http://buytaert.net/the-future-of-decoupled-drupal.

Drupal 8 is going to be huge. Although, I'm doing Angular + Node now, I'm very excited and anticipating using it in conjunction with React, Angular, Node, and Solr.

I left the Drupal world right before Drupal 7 was introduced. While there were many reasons for this, the speed and insane db structure (and resulting queries) were a big cause of my switch. Another big issue was the fact that while Drush and the Features module made it easier to avoid having to click around in the admin interface, I still had to configure too much through the Drupal back-end UI (with much of this configuration stored in the db, which I understand in context but still really hate).

Have these issues been resolved in later versions? Because there was a lot about Drupal that I did like.

Yes, you could consider Drupal 8 basically a rewrite.

Massive modernization. Most high-level concepts remain the same. The implementation became much better. And it's a joy instead of a pain to extend/customize.

I recommend you to take a look :) See https://www.drupal.org/drupal-8.0 — RC1 was tagged _yesterday_.

It sounds like you will particularly like the Configuration System. See https://www.chapterthree.com/blog/principles-configuration-m...

That sounds great! I'll definitely look into it, as I still get many requests for Drupal developers.

Drupal and Wordpress started as blog post generators. Developers kept adding features. It's economics because it's easier and cheaper to build a REST server on top of either one than to implement SEO and media asset management on a custom Rails or Express app. They evolved and have parts related to the original purpose stuck in the code base like an appendix. Why are comments attached to every piece of content? All that has been refactored and put in non default modules in Drupal 8 which is built with a Sinatra style router on top of Symphony.

http://qi-cms.com/ this is a CMS which only does content management. It is not free.

Hi!

Relax creator here :)

Read most of comments here and I think there is still a lot users didn't try out on Relax.

Relax is not just a page builder, it provides a way of creating schemas in a graphic ui, and the magic happens when you create a template for that schema and link data to components by drag and drop on the page builder.

Will eventually make some screencasts showing some cool features that past unnoticed at first glance.

Also Relax is modular, developers can create react components that will work perfect with the page builder.

Thanks all for the feedback! Keep it coming!

Quick suggestion; grab ShareX and make some .webm's showcasing Relax for your landing page. Much more accessible than learning how it all works. People want to see results.

Wasn't expecting this sudden inflow since it isn't even in beta version, so didn't prepare anything to showcase it. I'll be working in refactoring it to use graphQL and relay and then will make some videos to showcase it :)

Is it just me or is the barrier of getting apps like this working seem silly?

You git clone the repo (assuming you have git installed). You then have to npm install (assuming you have node installed). You then have to npm install sharp. But before sharp can work, you have to npm install node-gyp. But in before that can work, you have to make sure you're using a specific version of Python, specific versions of Visual Studio (2010 and 2015 both seem to fail), an SDK, and then run some console commands to set the WindowsSDKDir.

After you spend 30 minutes downloading and uninstalling and re-installing different version of Visual Studio and SDKs and sorting out other error messages, you're finally back to trying to install sharp. You install sharp, but wait, then you need to download this zip file and change your environment variables and PATH variables, which you have to Google to remember how to do each time because it's done so rarely.

This is obviously all feasible and to an experienced developer not intimidating, but for someone who's on a Windows machine and new to node, it doesn't seem like simply getting a package running should be this difficult in 2015. The demo is broken and I wanted to check it out, but it's just not worth the effort.

Fire up a Linux VM and get going in 15 minutes?

If you want to develop on a Windows machine, unless you just want to do .NET with Visual Studio, you're asking for trouble.

Just install Linux, it's much more user friendly.

I use Linux at home, but I was attempting this at work where it's Windows. I know Linux is much easier in this regard, but most more-beginner programmers are still Windows (or sometimes OSX).

This is quite the accomplishment for 1 developer. Haters going to hate, of course there will be problems/bugs. But I think we should encourage people for doing spectacular things, rather than gripe. Great job and keep it up!

Thanks mate! Type of feedback that keeps me working on this full time :)

It's very slick, but also rather confusing. Perhaps in future releases you can work towards making the page creation process more structured and predictable.

Will need an ux designer working fulltime with me, I'm not the best in that area, so a lot of work to be done there still :)

https://raw.githubusercontent.com/relax/relax/gh-pages/asset... shows the key features are WYSIWYG-style building of entire HTML pages.

This is not a Content Management System, but a Page Management System. A CMS works with structured content and the relations between those pieces of structured content. It allows you to model the data it needs to store, receive (forms) and render. So you can then reuse, combine and display that data in any way you need.

(Many projects/people conflate "page builder" with "CMS".)

That being said, this looks very nice :) There totally are use cases for an easy-to-use page builder :)

> Many projects/people conflate "page builder" with "CMS"

That's because there's no clear bright line between the two. I've created systems that lie on many points between these two extremes.

Sometimes the page metaphor is as simple as it sounds. Sometimes pages pull in structured content or are placeholders for a subtree of structured content. Sometimes the page structure plus metadata IS the structured content.

True, there's not always a clear distinction.

But giving lots of WYSIWYG-esque options to the content creator is a sure way to end up with unstructured content that cannot be reused, because it's got so much garbage HTML in it, and so few semantics.

Relax actually acts as a complete cms, it is not just a page builder, check our schema feature. You can even create templates for the schemas you create on the page builder and link data to components with drag and drop :)

Could you add screenshots for that too?

Sounds interesting! :)

Will do after the refactoring I'm doing now to use GraphQL with Relay and React 0.14, will take a few days but will definitely raise the bar

My major concern with a CMS that delivers a front-end is that it must to be able to deliver "raw" HTML to be accessible and support search engines.

Yes search engines can index javascript but I still see a requirement of any CMS to deliver html first and foremost.

Well the real question is: "is it isomorphic?"

Relax does server side rendering with cache, so it is indexed by any search engine.

It does. Most React apps are trivial to make universal and Relax does indeed deliver raw HTML.

Completely off-topic, but I really like the logo. Who made it?

I wouldn't say the logo of the thing posted is off-topic.

Looks promising but the demo app is very slow. When I pick a CMS, the tech stack is a consideration but I scrutanize the admin interface much much more.

The demo clearly seems to be deployed on hardware not designed to handle the kind of traffic HN generates. When I first posted this, it was working just fine. Now it won't even load.

P.S. I'm not the author.

>When I pick a CMS, the tech stack is a consideration but I scrutanize the admin interface much much more.

Right, I agree. And interestingly, I'm firmly of the opinion this is one of the reasons Wordpress continues to win in this space; albeit for familiarity reasons rather than it being a paragon of good UX, and despite it's core and plugin system being incredibly ugly in too many ways.

Relax had an enormous spike of traffic that I wasn't expecting, in the meantime upgraded the server a bit to support the traffic it was getting. There is still of course work to do to optimize it

Out of curiosity, was the server side rendering the cause of this issue?

It was simply the huge traffic inflow and our server had only one core, poor thing ahah. We've upgraded it to only two cores and it's day to night difference. Server side of course has some weight but it has caching so it is quite fast.

Major problem for now is that in some places it still doesn't retrieve data with the right projection, for example when creating a menu it loads all the pages with everything in it. That's why I'm switching to Relay to make this easy pie and more reliable

From a "site-builder" perspective, I find this to be an excellent balance between high and low level interface. Perhaps less capable than something like webflow, but the learning curve here is a piece of cake. But unfortunately, the person who will feel freed by ease of use will likely be nonplussed at installation.

I wanted to test the admin but in Firefox (v43 Developper Edition) it doesn't work at all, I'm just getting the menus but the page body is empty. It works under Chrome.

Anyone tested it with Firefox?

There's an issue created for that https://github.com/relax/relax/issues/45 will take care of it after the Relay refactoring

Avoid the media section if you are at work - it appears to have been subject to some abuse already.

Reply on news.ycombinator.com