Keystone-classic: Why keystone reinvent wheel in couples areas ?

[arturkasperek]

In that areas exists libs:

• REST api generation + ORM - https://feathersjs.com/
  That tool supports ORM like sequalize or mongoose, it also helps in generating CRUD api
• generation CRUD UI from schema and validation - https://github.com/mozilla-services/react-jsonschema-form
  I sow that keystone team was working long time on nested list, that react json schema supports out of box nested structure, also as name of lib suggest it uses jsonschema to validate so it's pretty good tool for making CRUD UI and also extra validate. Without problem with that tool is possible to
  make custom fields
• admin panel skeleton - https://github.com/marmelab/admin-on-rest
  It could be used as a skeleton for admin panel, supports authentication, provide helpers to adopt own api

I'm wondering if this is a good way to continue work on the project in current shape. I think Keystone shouldn't focus on creating DB schemas and generating API, it should use some other tool like feathejs which support SQL DBs and no SQL dbs like mongo. Also I think we should't generate UI since we have already done great tool for that, react jsonschema form. What are your thoughts @JedWatson @jossmac @mxstbr ?

[JedWatson]

Hi @arturkasperek

Thanks for asking the question. For one thing, Keystone has existed for longer than any of the projects you've mentioned, so "reinventing the wheel" is not really a thing I think it is fair say.

FeathersJS is something we've looked at several times over the last couple of years, but in the current version we are tightly coupled to mongoose which does the same thing (except REST API generation)

Decoupling this is something we're looking into long term but at the moment we're committed to publishing a stable version of what's there and switching ORM layers would be a breaking change for the many many projects that are already built on Keystone and as such will not be done lightly.

jsonschema-form generates forms from jsonschema with validation, and has some rich functionality that we don't in Keystone yet; but it doesn't match up 1:1 and there are other things we do based on our FieldTypes concept (including matching filter UI and column renderers to field types) so even if we were to use it under the hood, it doesn't serve all the requirements Keystone has.

And we've also looked at admin-on-rest, which looks fantastic and I mean no disrespect to other projects here. But it doesn't have the wholistic approach to defining lists and providing an "out of the box" solution that Keystone does so merging the two projects would be difficult.

In summary, certainly all these projects have some crossover but different focuses which makes it hard to wrap them together into something that feels like a coherent solution, which is Keystone's goal. Swapping out at this point would require a lot of work, and throwing away a lot of our own code that has matured over several years to achieve a specific set of goals.

[arturkasperek]

Ok, I'll try on my own build from that tools something similar to keystone