
A CMS with no server and 18 lines of configuration - owenm
https://www.netlify.com/blog/2017/08/17/a-complete-cms-with-no-server-and-18-lines-of-code/
======
toddmorey
A bit of context as there seems to be confusion: building a git-based website
with content as markdown / yaml / json / etc is a pretty pleasant way to work.
Changes are fast and easy, and branching and rolling back works really well.
Git is really good at what it does for both code and content.

The only problem is it typically locks out less-technical contributors, so
it's often with a bit of sad resolve that I've then brought Wordpress into the
equation—just to empower other editors.

This is an alternative. The Netlify CMS cleverly provides CMS UI that then
commits editors' changes via git (with no git knowledge needed), so they look
to me just like another contributor. Since content is managed in static files,
any participant can use any tool to to participate.

Some developers love Wordpress with it's ecosystem of plugins and
capabilities. This is not for them. Other developers would rather not run
Wordpress, yet are just looking for a way to bring in other contributors to a
web project, working in a compatible workflow. Those devs, I think, will
relate to the ideas of this CMS.

~~~
rjzzleep
I still don't fully grasp it. What's the advantage here? Besides the fact that
Netlify provides a CDN when you decide to use them(which granted can be very
helpful to some people).

I see the appeal against Wordpress. Wordpress is hell to integrate, slow and a
security nightmare. But I don't see the advantage compared to, say Kirby.

There's a post somewhere down below saying smashingmagazine moved to netlify
from a Rails, Shopify, Kirby mix[1]. "move would need to include solutions for
a decoupled CMS, comments engine, eCommerce platform, and member login."

What Netlify provides, reminds me of what parse used to provide. Except that
it adds a CMS and targets Web applications with identity[2] etc. They sell a
client facing website platform. Good for them. But that's not what the post is
about. So yeah, I do find it misleading.

[1]: [https://www.netlify.com/blog/2017/11/21/smashing-magazine-
is...](https://www.netlify.com/blog/2017/11/21/smashing-magazine-is-now-live-
on-netlify/)

[2]:
[https://www.netlify.com/docs/identity/](https://www.netlify.com/docs/identity/)

~~~
bobfunk
Netlify CMS is a self-standing open-source project. We maintain it and are
puring a lot of resources into it, because we think it's really important
there's a good open-source solution on the market for projects built with
static site generators.

However, the CMS itself is not tied to our deployment and automation platform.
It can also be setup to work for GitHub pages or self-hosted setups.

The basic idea is that's its an editor friendly content management UI for
persisted data stored in a GitHub repository. What you do with that data is up
to you.

~~~
detaro
> _The basic idea is that 's its an editor friendly content management UI for
> persisted data stored in a GitHub repository._

Since it was discussed in a different subthread: If you would describe it like
that, why isn't something straightforward like that the blog post title?

------
icebraining
It has 18 lines of _configuration_. The actual CMS (cms.js/css) has almost 2M
characters.

The demos is cute and all, but not really different from the many other
existing CMSs for static site generators.

That said, I do think it's good we're finally having some options for this
model besides Movable Type, which has been around for 18 years, but which is
too expensive for the needs of many.

~~~
erquhart
Post author here: There's definitely no shortage of options - the CMS exists
to fill a very specific trifecta that we believe are critical for modern
static development. It is:

1\. Git based, which is how devs are working increasingly

2\. Highly extensible, from backends to editor plugins

3\. It's open source

As a bonus, it's very easy to hack on - just a single page app written in
React.

~~~
mcguire
" _...just a single page app written in React._ "

Having been involved in a few single page apps, I'd like to point out that
JavaScript is a Turing complete programming language. There is no "just" about
it. It may or may not be easy to work with, but the fact that it is a single
page app or that it is React, had nothing to do with the matter.

After all, php is "just a web page with some templating commands" (and look at
where that gets you).

Also, when you are enjoying that warm feeling from being "serverless", bear in
mind that building something you value around someone else's service,
especially if you aren't paying them for the privilege, may not be a
spectacular idea.

This message brought to you by the American Society of Cynics. Pointing out
that your glass is half empty is our calling.

~~~
prophesi
Uhh, what? It being written as a single-page React Javascript app means that
if you're a web dev with React under your belt, then it won't be tough for you
to jump in and extend the CMS code[1]. And it's licensed under MIT, so you can
fork and do what you will with it.

And you don't have to use Netlify's service with their Netlify-CMS. Their
step-by-step guide uses it, but that's only because they obviously want to
promote their service[2] and it's the easiest way to get it all set up. You'd
otherwise just host the CMS page at /admin of your site and configure a
webhook to deploy your site on a push event.

[1] Unless your point is just that programming is hard. Which is obviously
true.

[2] Though their service is pretty shweet as they put your assets on
cloudflare and handle the webhooks for you.

~~~
_fool
Disclaimer: I work for Netlify.

Minor correction to your 2nd footnote: We put your assets on our CDN - some of
which is served by amazon's Cloudfront. We don't use Cloudflare's services to
run our CDN :)

------
domtron_vox
Just adding my 2 cents.

I'm creating a website for my parent's farm. Right now I'm using netlify for
hosting(free), metal smith as generation, and netlifycms so my parents can
edit the content.

For example we raise registered goats so we need to add info for each goat to
the web site. I added a new collection for goats, configured it to have the
right fields, and added the needed layouts to metalsmith. The information is
then used in creating both a summary page that lists all the goats and
individual pages for each goat. Only thing I have to pay for is the domain.

I'm really liking it so far. It seems to be very flexible with the ability to
extend the code and write your own widgets.

My only complaint about the CMS is the documentation is lacking so you have to
dig through code to fix some issues.

Thanks for making this netlifycms devs. :)

~~~
libertyEQ
Since you have a real world example of this solving your problems, I'd be
curious to know if having the CMS funtionality available in an Electron
desktop app, using a VPS (e.g. Digital Ocean) to host your metalsmith
instance, and fronting it with Cloudflare would be of interest?

~~~
Operyl
Wouldn’t that complicate their simple solution? I don’t think they wanted to
deal with all of that.

~~~
domtron_vox
I would have to agree with Operyl. I don't have a reason to use the CMS in a
desktop app and the site will be pretty low traffic, probably 20-30 unique
visits a year or less, and all of it local so I doubt cloudflare would be
needed. And I would netlify would have something similar protecting their
servers.

That said, it would probably not be that hard to create that electron app. You
just need to include 3 files to get netlifycms to work.

------
yodon
Once you’ve made the switch to a static front end (eg. a static react front
end where the browser loads one file each of html, JS, and css and after that
it just exchanges JSON content packets with the server), Netlify’s static
content pattern starts to look really natural and a much more modern cloud
architecture than old school Wordpress servers running half a million lines of
PHP on SQL backends.

~~~
dreamfactored
The irony is that this is the model which DB-based front and back end
integration replaced, and for very good reasons. If you've been working with
CMS's for over 10 years, this approach looks archaic and inflexible.

~~~
yodon
Can you elaborate?

~~~
dreamfactored
Static pages with placeholders dates back to Perl and the start of PHP. The
original CMS model was to separate back and front end e.g. Vignette (and TOGAF
guidelines ftm). DB CMS's used to generate static pages for display.

These all turned out to be lousy approaches when it came to UGC,
personalisation, migration and URL paths, authenticated content, non-technical
business users, team authoring and non-trivial workflows (e.g. picture desks),
content reuse and contextualisation, evolving functionality (a split front and
back system can require 2 dev streams kept in sync like trying to ride 2
horses).

Integrated back and front end systems was the start of solving these issues
and has evolved to SaaS for non-complex use cases. If you look at Wordpress
and Drupal, they have been adapting over many years answering these kind of
questions and you'll see that they are now starting to address multiple front
end channels, PWA and so on.

Old versions of Drupal for example used to allow pages to be rendered to file
for faster delivery. However, it turned out that the number of pages grew
towards infinity due to dynamic variants of pages (making server and file
system into the bottleneck), and that CDN's just became a much better way to
do this. Likewise, work was started on a materialised views layer to optimise
DB calls until it was discovered that PHP object caching had become very
effective and made this redundant.

A static generator could be a good app for a developer to blog but this is
niche and it is about the worst choice possible for almost all organisation-
based CMS users.

~~~
yodon
Thanks for that, very helpful. I do wonder if you may be seeing the new
architecture as too rigidly identical to the old architecture, specifically in
that the templating/page personalization can now be easily moved to the front
end rather than needing to be handled on the backend like in days of old. This
front end rendering approach allows the browser to pull down one JSON blob of
possibly dynamically extracted user-customizing data (first name, last name,
items in their character loadout, whatever happens to be relevant) and one or
more JSON files of static template content, fold the JSON blobs together
exactly as one would have done on the server, and present a fully customized
page to the user in a way that accomplishes the goals you articulated (I
think) while keeping the templates static and their delivery serverless, fast,
and cheap. Are there things you see that I’m missing in that architecture?
(I’m admittedly new to these aspects of the CMS world but trying to understand
the issues)

~~~
dreamfactored
I just don't think it's a new approach at an architectural level and I don't
see any gains (unlike say, AWS Lambda).

For example, I consulted to a large national broadcaster about 6 or 7 years
ago who had created a legacy CMS which rendered XML/XSLT to reduce bandwidth,
and the user's browser compiled to HTML in much the same way you describe. It
would have been interesting as a tech demo when it was first created about 10
years ago and would have made a good HN blog post. But as a production CMS it
was completely unmanageable, prevented them doing the things they wanted to do
at a business level, and grew into a tentacled legacy blob which was extremely
expensive to migrate off. It was an embarrassment to the tech management and
they were open to switching tech even if that meant recycling their large in-
house dev team. In the end the cost of their tech experiment which had gone
out of control ended up in many millions.

Developers building CMS's is an established anti-pattern with a problem space
that is quite hard to understand unless you have been working with users at
large orgs for a while. Go and look at how many modules are on WP or Drupal -
10's of thousands, each one which will have had months to years of dev time.
Each one represents real use cases that organisations had which was not solved
by what developers imagined managing and publishing content to entail.

~~~
yodon
Admittedly naive analysis here, but it seems like there are two distinct
classes of issue you are raising. The first class of issue is plugin module
availability, the second is data model/schema/information architecture. I may
be wrong, but I’m guessing the flaws you saw in the National broadcaster’s
system were more at the schema/information architecture level than the plugin
ecosystem level, particularly given their willingness to throw devs at it (a
bad schema deeply baked into a system is much harder to patch than a lack of
extension modules). Now that we’ve reached an era with at least three CMS
backends with heavily battle-tested information architectures (I’m thinking
WP, Drupal, and Joomla, and there are probably others) it seems like a venture
funded startup like Netlify should be able to propose a viable information
architecture (or at least encourage/show customers how to implement one if
their system is too flexible to enforce a good IA). Once there’s a good IA in
place, my (admittedly naive) assumption is that the library of npm packages
becomes the front-end equivalent of the WP store and on the backend you always
still have the opportunity to procedurally generate any content or templates
you want (potentially using WP or drupal or whatever as your JSON constructor
kit). I totally hear your concern that random devs building CMS’s is a bad
idea. That said, a well funded competitor going after WP with a “more modern”
and “more secure” architecture (and well designed information architecture)
doesn’t seem like a dumb idea to me given how much money WP makes and how many
objections many people have to its legacy constraints.

~~~
dreamfactored
The business argument isn't there. Drupal for example has over a decade's lead
and a developer community and pace of innovation that no private company of
any size can match, let alone a startup. They are now competing with the last
man standing in enterprise, Adobe. Even IBM are MS aren't really in the space
any more. For business lower end, you cannot compete with Wordpress for price
and developer availability. For personal, you would have a very tough job to
even catch up with the mindshare of Wix and Squarespace, let alone exceed the
products sufficiently to take their market, which is super low value unless
you can bag most of it. You mention security a few times - do you think any
privately funded CMS has a dedicated security team covering both core and
community code as Drupal does? I will bet you a bridge that a private
company's development resources get diverted to adding features in favour of
security to sell the next upgrade.

As for IA/schema, one of the major reasons to use a dynamic CMS is that you
configure your own because there is no such thing as a generic 'good IA' for
any non-trivial content (recipes are probably the closest but even there most
schemas are too limited for professional use). If you are working off a fixed
IA, you may as well just use a low end SaaS. Drupal is particularly strong in
IA, offering nested object modelling, workflow authoring, content versioning
(now including staged sets of content so you can version sections or hub
landing pages).

You then need to start adding considerations like BigPipe, or offline first
access with eventual consistency for edits, and how all these play with access
levels for granular pieces of content which may sit within pages depending on
who's viewing, ditto contextual content. These are just a few things off the
top of my head which CMS's start needing to provide.

If I was creating something in this space, I might look at small serverless
modular apps performing simple use cases in a very polished way which could be
used alone, or very easily integrated with major CMS's (including building,
maintaining, and promoting those integrations). But possibly better to look at
SaaS layers which sit on top and address digital experience and orchestrate
content from multiple backends across multiple front end channels e.g.
gamification, recommendations etc. A lot of money there and few open source
solutions. (Even something as simple as buffer which just publishes from its
backend to major social media channels has very little competition and is
quite expensive. I'd imagine something which could simply manage a flow of
content to and from social media, sites, apps could do well, even before you
started adding in any intelligence around that content and your users.)

------
peterburkimsher
I like it. Wordpress charges extra for plugins, Appspot is blocked in China,
Rhcloud closed down, and I registered Github pages while they still gave out
.com subdomains.

My personal website is written in Markdown and loaded & converted to HTML on
load using JavaScript. I hard-coded the whole thing a few years ago, and I
dread maintaining it so I rarely post.

Now there's a decent CMS that's targeted to Github, I'll experiment with it
and seriously consider migrating my website over to Netlify.

~~~
lima
rhcloud did not shut down, it was superseded by OpenShift.io.

~~~
peterburkimsher
OpenShift.io is "Currently waitlisting registrants." and I think it will only
give .io subdomains, not .com subdomains.

I like being able to give my personal website as
[http://peterburk.github.com](http://peterburk.github.com) because the .com
subdomain makes it sound more professional somehow. Non-English speakers will
recognise a .com when they might not recognise .io as a URL.

------
wilsonfiifi
Disclaimer: I'm and python and go(lang) developer.

The main problem I've had with regular CMSs (DjangoCMS, Wagtail, ...), is the
sometimes steep learning curve associated with them and the less than ideal
deployment options (especially if you've been spoilt by Heroku, Dokku et al.).

I like the idea of headless CMSs but currently the only available open source
ones that i know of are written in PHP or Javascript (Node.js). Also when
you're done building your data models and adding your content, you still have
to build/deploy another app to access the data.

Flat file and static CMSs (Lektor for example) are great until you need some
server side processing and then you're forced to make use of a 3rd party
provider (for form processing and so on).

For me, the sweet spot would be a headless CMS that behaves like a static site
generator and can be embedded in my Flask app as an extension.

~~~
WorldMaker
Why not both? Most frameworks (including Flask) already have static file/page
tools/middleware. Just set up the static file hosting part of your framework.
At that point it is "merely" a CI/CD issue to compile your static site and
deliver it to the static directory your framework expects.

Python frameworks, owing to the Django CDN-focused approach, tend to make
static assets harder than they have to be, so the answer to a better approach
for Python in specific is often to setup the static asset hosting more
directly in your web server than in your framework. But that too is "just" a
configuration/CI/CD issue.

Finally, an approach that is increasingly common is simply to treat your own
dynamic server-side assets like a "3rd-party" API: host it on something like
api.example.com and let your main website just be the static app served from a
static file server/CDN.

------
dankohn1
As an alternative, I've found a lot of non-technical people are very
comfortable using [http://prose.io/](http://prose.io/) to edit markdown files.
Saves are GitHub commits.

------
Zaheer
This is awesome. I haven't tried it yet but is exactly what I've been looking
for. I'd like the ease-of-use aspect of CMS to provide to non-technical users
with the flexibility of a custom static site generator. Wordpress is super
bloated and hard to use for end-users these days. Maintenance, etc is all a
headache. Other simple CMS's are paid services and usually don't give a lot of
flexibility. Netlify seems like something I could use to make websites to
users and not have to worry about too much maintenance / cost afterwards.

------
KeitIG
TL,DR: "it’s a single page app written in React and built on Git"

I am really curious to see how it can scale with a loooot of content.

~~~
dfcowell
I imagine it would scale about as well as the git* API backing it up, given
that the content list etc. are all pulled from the git host's API (Github in
this case).

I like the way it uses pull requests to handle drafts. A couple of clever
build scripts in the repo would make for a pretty sweet deployment workflow.

I'm not super keen on the way it stores uploaded assets though. I understand
the benefit of simplicity in only targeting a single API, but it would be nice
to target a cloud hosting service (like GCE/AWS storage) for asset uploads.

------
alxlaz
A very long time ago, there used to be these programs that helped you write,
maintain and manage static HTML websites (this was back when CGI was more or
less a recent invention, and the only way to have access to it was to run your
own server, which was not an option for everyone). It was basically a WYSIWYG
HTML editor a la FrontPage (oh, the horror!) + an FTP client + some basic
version control and project management all in one solution.

Unix geeks being Unix geeks would bake their own concoctions, with Emacs, Perl
and whatnot. I had one lying around for years, dragged kicking and screaming
out of the foggy Interwebs of 1998.

This sort of tools were needed because _back then_ , a static website with
hundreds, maybe thousands of pages was not at all unheard of. My first paying
gig was for a computer magazine which had, in 2002, just upgraded its website
to a fancy dynamic thing (it was a CMS, but the system it ran predated the
term, I believe). Prior to that, they had a static website, containing a lot
of the articles that had been published, mailing list archives (statically
generated -- the mail server that was running it was sitting in the corner of
an office and it had a cron job doing the archiving) and a bunch of other
things. It definitely had thousands of pages, and a lot of them were hand-
written.

If you are willing to forgo a couple of things, like managing relative paths,
it is _remarkably_ easy to get somewhat primitive (but sufficient) templating
support and management out of nothing but your favourite shell which also
produces remarkably clean output. At the end of the day, generating a static
HTML page largely consists of concatenating a header, body and footer section,
then replacing a number of variables.

The script I use today barely has 150 lines, about a third of which are
comments. The only thing I need which it does not do is automatically generate
RSS entries, which I think would take maybe another 50 lines or so, but I am
just too lazy.

For a while, I also used a GUI script I wrote in an afternoon or so, which
would help me with things like creating new pages automatically (i.e. writing
the initial boilerplate in the right directory), but I found myself using it
very rarely or not at all. I thought I would write an emacs mode for it, but
it also turned out I just do not really need one.

If you run a blog with a high posting rate, you definitely need a real thing,
but if you post maybe one or two things a week... meh. I have been using this
contraption for almost two years now, and while some things require manual
intervention, I think I have definitely spent less time working around its
shortcoming than fiddling with WordPress and managing the whole LAMP (well
OpenBSD-Nginx-MP) thing behind it and whatnot.

There are also things like Pelikan, which I am quite certain HN knows about,
which are even more flexible than anything one writes by themselves.

------
reacharavindh
I have been using Filemanager:
[https://henriquedias.com/filemanager/](https://henriquedias.com/filemanager/)

No affiliation with the developer. Just sharing based on relevance.

------
amelius
Can somebody quickly explain where you typically host your CMS, and what are
the costs?

Also, isn't this against the TOS of GitHub?

~~~
erquhart
Cost isn't the big issue, there are plenty of ways to do it for free. I'm
curious why you think this is against GitHub's TOS? We're creating commits and
pull requests via their API, which is exactly why the API exists, programmatic
interaction with the service.

~~~
amelius
> Cost isn't the big issue, there are plenty of ways to do it for free.

Okay, but I was also thinking how easy it would be, for non-programmers. I.e.,
what would be the easiest way to host it without cost?

> I'm curious why you think this is against GitHub's TOS? We're creating
> commits and pull requests via their API, which is exactly why the API
> exists, programmatic interaction with the service.

Yes, but you would be committing data, not code.

Also, I suppose the data would not be not human-friendly to read, so that's
another step away from typical github use.

~~~
erquhart
It's meant to be implemented by a developer, but it doesn't take much skill,
and can be hosted for free on a number of services. I was a champion of
Netlify well before I became an employee, so I still shamelessly plug them as
the way to host static.

Regarding what we're committing, it's definitely human friendly, mostly
markdown, or else json/yaml/toml/etc, nothing crazy. It's a completely
legitimate use, same kind of data that GitHub's own Pages product uses.

~~~
amelius
Thanks for the explanation.

I wonder though, if a developer needs to find/provide hosting, then why not
use a local db (or even a local git-repo) instead of github? With current data
storage solutions, installing could be as simple as one line of code.

~~~
erquhart
The CMS is specifically made to work with Git, because so many developers are
already using it for the rest of their site development. That said, it's not
impossible to write a non-git backend, but it's heavily bent that way at the
moment.

------
nfrankel
I don't understand the goal. So it's a server CMS, which stores data in
Github. What are the advantages of a full-fledged CMS like WordPress? Over a
static site generator like Jekyll?

Oh yes, it's based on NodeJS, so it's hype!

~~~
icebraining
This doesn't replace Jekyll, it's a CMS for those sites.

The advantage of these tools is that you can get a statically generated site
without having to use terminal commands or git. It's perfect if you're setting
up a simple site for non-technical clients, then they can manage their own
content and you don't have to babysit Wordpress or worry about scaling.

~~~
erquhart
It's actually great for highly complex, high traffic setups as well - Smashing
Magazine was a conglomerate site using Wordpress, Kirby, Rails, and Shopify,
and are now entirely static (10x faster literally) and using Netlify CMS for
content management. If you haven't checked out their site lately you should!

[https://www.smashingmagazine.com](https://www.smashingmagazine.com)

[https://www.netlify.com/blog/2017/11/21/smashing-magazine-
is...](https://www.netlify.com/blog/2017/11/21/smashing-magazine-is-now-live-
on-netlify/)

------
diminish
> no server?

I was excited but you use github and where will that local http-server be
deployed?

~~~
kostarelo
GitHub is not managed by you and by hosting a static site on GH Pages, you
really have no server. The CMS that the auhor refers to is a frontend client-
based library that you include in your static site code and communicates
directly with GitHub to manage your content. It's a UI for GitHub.

~~~
diminish
you can use WordPress API at WordPress.com or elsewhere if "no server" means
"not my server".

and where do you put the status site code?

~~~
kostarelo
What do you mean by status site code?

~~~
diminish
sorry meant "static site code"

------
mschwaig
I guess this is also ok with GitHubs TOS since you eventually use their built-
in features for static site generation to serve your content instead of
abusing the Repo itself as a CMS.

Is that right?

~~~
erquhart
Yep, we're managing Git content through their API, which is exactly the kind
of thing the API exists for. There are working PR's for open for Bitbucket and
GitLab backends too, those will be out soon.

------
amelius
Where would you store large images, or video?

~~~
erquhart
Asset storage integrations are supported, but it’s very early. That’s one area
where we expect to strengthen after 1.0 drops in December.

That said, you don’t need a direct integration to work with a service - you
could upload files to a service and enter the url into the cms as a stopgap.

------
butz
Is there any way to use any other backend, e.g. store files to own server?

~~~
erquhart
Yes, the backend system is actually pluggable, so anyone can write one to fit
their use case.

~~~
AstroJetson
Can you point to the documentation for that? Your CMS is cool, I'd like to use
it with a self hosted server.

Thanks!

~~~
erquhart
No documentation for this yet, but here's the PR to add the file system
backend: [https://github.com/netlify/netlify-
cms/pull/786](https://github.com/netlify/netlify-cms/pull/786)

We have a lively community on Spectrum if you have questions:
[https://spectrum.chat/netlify-cms](https://spectrum.chat/netlify-cms)

~~~
AstroJetson
Thanks!

------
kripy
Rise of the headless CMS.

