Alternative path for schema.prisma

[gautamsi]

I am creating a monorepo which has separate next app and keystone app.

I am facing challenge in writing massive amount of queries. I could use little help from the experimental apis.

How can we use keystone to share the .keystone/api and .prisma in a different repo (inside monorepo) ?

any possibility? has anyone tried this?

[flexdinesh]

Hey @gautamsi! This is a great question and I'm sure it will help others in the community as well when they stumble through this discussion.

When and how to invoke the Keystone APIs:

Client environments (Eg. Browser)

To invoke Keystone APIs from a client environment, the GraphQL API or a custom REST endpoint should be used.

Independent server environments hosted separately (Eg. REST API of another service, independent webhooks, etc)

Similar to client environments, to invoke Keystone APIs from another server environment, the GraphQL API or a custom REST endpoint should be used.

The independent server environment won't have information or code related to the Keystone server and the only way to communicate to the Keystone server is via the URL to the GraphQL API or a custom REST API (if you extended the keystone server to build custom REST endpoints).

Server environments where Keystone is hosted (Eg. In embedded mode with Next.js, Next.js routes, scripts for your server, external packages built for Keystone, etc)

This was the goal of the experimental Node API - to see how we could improve the data CRUD experience in Keystone using an exportable API. Long story short, the current experimental Node API is a sudo lists export that has its own prisma instance without user's session information. So anything you do with the lists object will bypass Keystone's access control layer. This was always experimental, it might break in unexpected ways and there's a good chance it might get deprecated soon. We have plans to replace this lists export with a getContext export that will allow users to create a context object, using user's session if needed, to get full access to the entire Keystone data APIs (context.query, context.db, context.graphql, etc). We're not sure when it will be released but you can follow along the PR here.

To answer your question re sharing context in monorepos:

How can we use keystone to share the .keystone/api and .prisma in a different repo (inside monorepo)?

There are reasons why you shouldn't import keystone exports in a different package within a monorepo and the most important one is that some of these imports are dependent on your build. Eg. the node API, context types, prisma schema, graphql schema etc will all be generated only after you run build command (or postinstall in some cases) in your keystone repo. So your packages are not truly independent and you're better off building them within your keystone repo.

In case you need to build utilities or external packages that depend on Keystone context or the GraphQL types, you could do one of these two things now —

1. If your package will be used within Keystone server, make sure the utilities you're building don't import anything from keystone and instead receive the context (or anything you need) as an argument and type your utilities using generics. Once the new getContext API is merged, you will be able to do this in a easier way.
2. If your package won't be used within the Keystone server, you could use a codegen tool and make your package depend on the types generated from the codegen and use the GraphQL API for CRUD.

If it helps, the document field example is a monorepo although it doesn't have any separate package that needs access to the node API.
https://github.com/keystonejs/keystone/tree/main/examples/document-field-customisation

[dcousens]

@gautamsi did #8381 and #8307 resolve this problem for you?

[gautamsi]

Yes it did. Thanks