Adding the start of Keystone's New Interfaces

[JedWatson]

🎉🎉🎉 This is the first commit of Keystone's New Interfaces 🎉🎉🎉

As announced in our recent blog post How we're making Keystone more intuitive and powerful we have been experimenting with several improvements to Keystone and this is the first PR to land our work into the main keystone project.

We're taking a different approach to other changes we've made in the last two years, because these improvements will replace how you configure and run Keystone -- and they're still in the early stages of development. Also in scope is a new Admin UI built on Next.js with a new set of Design System components.

Even though they're not ready for use, we've spiked these ideas thoroughly enough to be confident about our approach and the benefits they will unlock for everyone using Keystone to move forward with them, and we want to do that work in the open so everyone in the community can follow along and contribute.

What are we doing?

At the core, we're changing how keystone is configured and run. This is part of what we mean by "interfaces" -- we're reimagining the API that keystone exposes to developers. This includes a new CLI, a new configuration + build model (inspired by Next.js) and a new functional way of defining schemas.

We've considered whether it's worth breaking Keystone's API very seriously and believe the benefits this creates to be worth the change; we're also hoping to end up in a state where the eventual upgrade can be done without too much effort.

One of the big things is Keystone will be able to separate the configuration process, from the build and deployment process, from the runtime process. Another is that Keystone's configuration is now atomic, which significantly reduces the complexity of the system.

Next up, we're building a new Admin UI. This is so we can clean up a lot of the internal architecture in ways that are hard to reverse-engineer into the existing app; and we can do a much better job of extensibility, permissions handling, and field validation (these priorities have been inspired by a lot of community feedback)

That goes along with a new design system to replace Arch UI that developers can theme to match their brand or application; as well as making it much easier to extend Keystone's Admin UI with your own workflows and interfaces, using our components.

We also want to improve Keystone's deployment story, including making it possible to host on Serverless infrastructure more naturally. To do this we've had to reduce our dependency on having an express middleware stack at the heart of Keystone's runtime; and that's meant rethinking session management and authentication to be more functional.

Ultimately this will make Keystone simpler, easier to understand, and more flexible.

What are we not doing?

We aren't rewriting most of Keystone. Although we're replacing the entry point, internally the new interfaces are spinning up a normal keystone instance and configuring it. This means that the field types, database adapters, access control, and GraphQL API are all being brought forward.

What does this mean?

We're adding a series of packages in private namespaces to the monorepo for now. We're not branching because we want to maintain the current interfaces for as long as necessary while we build new entry points around them.

Once the new interface packages are mature enough, we will publish them to npm for everyone to try out; but we won't hit feature parity on Day 1. It's important we give ourselves some room to get these right and smooth out the upgrade path as we go, and equally important that if you don't need features we haven't brought across yet, you can try out the new stuff.

Eventually (probably early 2021) we will replace the current "main" packages with these new ones and deprecate the old version; but we're going to make sure the new interfaces are mature and easy to upgrade to well before then.

So we're going to merge this PR fairly quickly, and then start iterating on the code alongside the current packages.

About where we're up to

Be aware that this code has come across from a separate spike and is currently extremely WIP. There are no tests yet, and we expect things to change considerably as we round out the functionality. There are also no docs! Nothing in the new interfaces is ready for real use yet. We'll be adding all these as the architecture and implementation matures.

Having said that, we're really excited to put this work out in the open so everyone can see how it's going!

Want to try them out?

The new examples are in the examples-next folder; if you get latest of the keystone repo and run yarn, that's all you need. Change into the directory of one of the new examples and run yarn dev to spin it up.

The new design system website is in the design-system/website folder -- similarly you can run yarn dev in there to check it out (it is very bare bones right now; we're adding components as we need them for the new Admin UI)

We hope you all like where we're going with this! Feel free to open discussions and talk to us about what you think, or what you'd like to see.

[changeset-bot]

💥 No Changeset

Latest commit: 85fdfca

Merging this PR will not cause any packages to be released. If these changes should not cause updates to packages in this repo, this is fine 🙂

If these changes should be published to npm, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR