You guys have a Dynamic Schema CMS!

[reggi]

I was looking for a project just like this! I just wrote out exactly what I wanted. I'm wondering your thoughts @JedWatson!!

https://gist.github.com/reggi/a54ee1cc617a44ede878

I'd love to see a text-editor page for the specific model template in the backend. I'd also love to be able to create a new model from the CMS itself.

This is not an issue and is open for discussion. Feel free to close immediately / tell me where to move this!

[JedWatson]

These goals are quite in-line with where we're going; except for the concept of being able to develop the schema within the system itself.

One big early decision was to build schemas programatically (i.e. in code) rather than through the CMS interface itself. I actually previously spent many years working on a CMS / web app platform (built on Coldfusion & SQL Server) that had a sophisticated UI for creating schemas - we stored store schema metadata in the database and generated SQL scripts to automatically manage the database, and generated the Admin UI from this metadata. A lot of Keystone is based on what worked (and solving what didn't) in that system.

The problem with allowing in-system schema changes is that you end up with serious difficulties in more sophisticated projects; if you're editing schema in the live environment, it's hard to handle backwards-compatibility, data migrations, sync across multiple development environments, write tests, etc. The whole workflow is fundamentally at war with proper dev / staging / release workflows, and version control. You end up with a smaller version of the same problem with templates too; you could create a draft (new) template in the database; but what happens when it relies on some new / changed functionality, or a migrated schema? eventually, every form of this that I've worked with falls down for these reasons.

Ultimately (in my experience) schema, functionality and templates are best handled in code, and with the mature version control workflows / testing and release procedures that already exist. So my focus with keystone is to make it as simple as possible to code the underlying parts of the system, and streamline as much as possible (removing boilerplate, without reducing flexibility).

Having said that, I think it would be excellent to end up with visual tools that integrate with this workflow; for example a form builder that can generate model code, a template editor, deployment manager, etc. These tools could be decoupled from the core system, and taken forward independently, and this decoupling means that the overall ecosystem is useful to a much broader audience.

I'm interested to hear more thoughts on this, and whether anyone has had different experience; there is theoretically no reason that eventually these issues couldn't be abstracted away (i.e. automated forking of a production environment to staging; live IDE-style code changes and git integration; and managed testing and deployment back to the production environment).

[reggi]

Thank you so much for this really detailed and eloquent explanation of the troubles you've had with building schemas through the CMS! This is great insight!

What about the API side of things? With services like prismic.io and firebase popping up, I feel like the issue of managing and maintaining backend data / content is rising to the surface of the tech community.

What excites me most about the opportunity here is I'd love a way to farm / gather / crowdsource / share / and iterate schemas. I'd really love to see progress being made on the standard organization of data with support for synonyms and internationalization for semantic data. I'd like for a way to showcase these schemas like schema.org does, and that's a little challenging if everyone is designing their schema in code thats locked away in their project and their is no native support for forking a schema.

[reggi]

Moreover, the problem that I'm experiencing is that as a full-stack developer / only developer for a company is that my day-to-day grind is a lot of data entry. I'm sick of writing repetitive HTML or worse copying and pasting HTML, violating DRY and making the codebase harder to maintain. I'm just so sick of changing typos. The CMS we use @shopify is limited in the data we can pull from it.

For instance if I wanted to include a "team members" section with, name, picture, start date, and url. I have to either write it by hand and mess with @shopify's crappy templating system liquid, which is so limiting that you cant even create an array. Right now I have created a really convoluted way of generating liquid with node so I can iterate over simple things, but this is crazy and if you could only see the kinds of things I was doing, your head might spin.

Im imagining a micro-service or open source codebase I could host my own server where one could put up to pipe data around to other services and have a complete backend and admin structure where anyone on a team can update the content.

Think of the idea I was talking about above as one small service, a way to display team members on a site, so useful because most CMS's don't provide it. But imagine you could do that for any kind of data, any kind of use case where you need a unique schema.

That was the rant portion! I'm expressing all of this because as more developers enter the workplace and more content is being generated this problem will exponentially grow. It's not gonna solve itself. Businesses shouldn't waste good talented developers on doing data entry, when they could be writing apps or interfaces, or meaningful progressive code. I'm worried for the future. But perhaps it's just me, and I haven't found a fix for all this. I'd love any advice on how to prevent what I'm taking about. This conversation is really outside the scope of keystonejs now, sorry for that @JedWatson!

Sorry to call out @shopify like that! I love what they do, as a backend developer my hands are tied when I'm using their system and it can get really frustrating. Plus I don't believe that this problem is specific to @shopify as a CMS. I think it's a problem with any static / conforming CMS. While I understand that, for the sake of simplicity a CMS needs to be straightforward, there is a growing demand for agility and a certain level of customization that happens with any site, shop, business, or app, and I believe that dynamic schemas like keystonejs are the way to go.

[morenoh149]

@reggi invited you to the slack