Hacker News Reader

Comment by BillinghamJ | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com