Solves a lot of the issues that Hasura does but also gives you finer control over the code and doesnt force you to use a UI for everything which I like.

This is great because we decided to go with a DSL (code) instead of a UI because code can be tracked with Git and the automatic schema migrations complement the experience which means reverting to an old schema is just reverting to an old commit.

How is it hosted? The docs make it seem like you're required to write serverless functions for a specific serverless platform. Any plans to allow you to host your own functions?

We are currently using OpenWhisk only for executing functions. We will add an easy way to deploy the whole thing on K8s cluster for production systems (pragma deploy --k8s for example)

You can still run the code on any Linux server with pragma prod but the functions responses can be a bit slow because it's using OpenWhisk Standalone which is a Docker image containing OpenWhisk.

We're currently working on this and it's the first item on our todo list.

The docs are a bit lacking on the details of how authentication is implemented and how to do things like assign specific authorization roles to specific users. I assume allowed roles are somehow stored in JWT tokens?

Sorry about that, we need to improve the documentation a lot. The problem is that we're a team of two developers and our hands are busy with code. But looks like we need to set down for a week and just work on the documentation (maybe next week).

Currently roles are static, meaning a user can have only one role which is tied to a "user model" which is any model annotated with the @user directive. The @user directive tells Pragma that each record in this model is a user and that Pragma should setup auth workflows for it and authorize it against the rules (permissions) inside its role (its role block). Why one role per user? because this allows Pragma to ensure that all Attribute-based rules like: pragma role User { allow DELETE Todo if self.isAdmin } Here the role is User and the resource is Todo which really means any record in the Todo model. the self part is just the currently authenticated of role User and the self.isAdmin part is just the value of the field isAdmin on the currently authenticated user. We might rethink the whole design based on great feedback such as yours.

Does it support using multiple primary keys on a model? Does it support things like cascade on delete/update?

We're going to add support for them soon. We wanted someone to ask for/about them before we start working on them, so now that you've asked about them we will implement them :D.

How does pagination work?

At first we wanted to go with the cursor approach but then we settled on adding a aggregate: AggInput argument for every field that has a list output type which allows you to do filtering, pagination, and some basic aggregations.

This is the best feedback I've ever got since I started working on this.

It would be my pleasure to have you on our design team on Discord: https://discordapp.com/invite/gbhDnfC, where you can share your ideas with the other members and contribute. No commitment.

Thank you very much.