API and database access

This is more like an ideological question rather than an issue in the current version.

What is the proposed way of creating a custom API endpoints? Is it just like this server.app.get('/api/doSomething', (req, res) => { for every endpoint that is required? Could there still be some server-side routing for such cases?

Is there a way to access Mongoose directly as earlier? So how to make more complicated database queries that custom APIs could require? I see that there are new adapters for different datasources but does this prevent using Mongoose directly?

It would be very nice to see TypeORM as the ORM layer but unfortunately it works best with TypeScript and might be therefore hard to integrate here. Although writing own adapters can be tricky and require lots of work.

There can be some answers already but these were my first questions after looking this new version which otherwise looks very promising.

[JedWatson]

@ttsirkia some really good points / questions here, going to see if I can help clear a couple of them up.

Internal APIs

The internal GraphQL APIs that @jesstelford is talking about are best thought of as an ORM layer. They ideally replace the usual things you’d get from mongoose like find() and update(), with the benefit of being built on top of Keystone’s internal abstractions (including field type logic and rules)

There’s no strong link between supporting things at the schema level (including custom mutations) and making them publicly available, although we’re still working through some of the tasks required to make it possible to create additional limited GraphQL endpoints (at the moment, there is only one, this will change soon)

But more complex queries, especially containing Mongo aggregation pipeline, are not possible.

I’m not sure that this is true, it’s what I’d expect custom queries and mutations to enable.

Raw database access

To answer your original question, yes the underlying database communication layer will always be exposed by the list, as was the case in Keystone 4. We’re hoping to make it less important, but will never stand in the way - especially because, as you noted, people need access to advanced features like aggregations etc.

Server can still use GraphQL, Mongoose queries, raw SQL or whatever.

This is the idea.

It’ll also be important for people migrating projects from older versions of keystone, which relied on a lot of mongoose usage.

Access Control

Before running queries, there can be very fine-grained access control etc. and I don’t see that a generic framework can provide all the needed control for this.

Have you had a look at our access control spec? It’s quite deep, and I’d be interesting in collecting use-cases that it doesn’t cover because we’re investing quite a lot in this part of Keystone 5.

One that came up recently was context-aware permissions (i.e a user can access certain fields on a model through some interfaces, like a query of related items, but not others) which is pretty interesting, but I’m hoping we can solve that by making custom queries and mutations easy to implement at the schema level.

[ttsirkia]

The third one has the following meaning:

• Search the trains which have been actually driven but are not running at the moment, which have been late more than the given limit and their departure time is between the given dates
• Create a group based on train’s number and type, calculate the average delay and the number of days when the limit has been reached
• Take only those groups which have at least three entries
• Sort them by using count and average, descending order
• Group them again so that the train type will be the key and add the individual trains to a list which belongs to this train type
• Limit the groups so that there are only the top ten trains in each group
• Sort the groups by the train type

Here is a picture:

Boxes are the train types, in each box there is a train number and how many times it has been late over the limit and what is the average delay.

There are so many aggregation pipeline stages and pipeline operators that I don’t see it very beneficial to implement all these to GraphQL. Therefore, I was asking that is there still a possibility to write these queries using Mongoose directly.

I’m not that familiar with GraphQL but I’m also wondering how easily you can make dynamical queries. I mean that you produce the query at runtime instead of having it ready in the code. As GraphQL is a string instead of nested objects (as in Mongoose), it requires at least a library to do that. Manipulating objects and arrays to construct the query is very simple and no injections can occur.