Hasura for Flutter

Hasura DDN generates a GraphQL API over the data sources you already have, with subscriptions, row and column permissions and custom logic in TypeScript, Python or Go, and that is a genuinely good trade. What it hands your Flutter app is a GraphQL document: typed once a code generator reads it against the schema, and a runtime error when the schema moves and nobody regenerated. Dartvel generates the client from the data model instead, so there is no query language between your app and your data.

// Hasura: a GraphQL document, typed by a code generator
query { articles(where: {published: {_eq: true}}) { id title } }

// Dartvel: the data model generates the client
final List<Article> all = await Article.all();
final Article? one = await Article.find(slug);

Dartvel: A typed Dart client generated from the model, plus GraphQL and OpenAPI endpoints

Hasura DDN: GraphQL subscriptions, generated for each model, in beta

Dartvel: Model change streams, also served as GraphQL subscriptions over SSE. Models do not sync to devices on their own yet

Dartvel: @DVModel(offline: ...): save() writes the device copy at once, and the queue is sent when the server can be reached

Hasura DDN: ModelPermissions in metadata files, in your repository

Dartvel: @DVBackendFunction, in the same repository as the app

Hasura DDN: Postgres, MySQL, SQL Server, Oracle, MongoDB, ClickHouse, Snowflake, BigQuery and more

In Hasura DDN a permission is a ModelPermissions object in an .hml metadata file: a filter over rows for each role, versioned with the project and built by the ddn CLI. Only the admin role gets access by default. A Dartvel policy is Dart beside the model it guards, so it is type-checked with the model, can call any function the backend can, and answers no for anything nobody registered.

DV.Auth.authorization.register<DVAuthUser, Article>(
    'Article.publish',
    (DVAuthUser user, Article article) =>
        article.authorId == user.id,
);

// a policy nobody registered answers no

A field marked @DVModel.sensitiveField() is kept out of logs and search, and encrypted: true seals it at rest.

The records layer under the adapters is built so a document database can sit behind the same data models. MongoDB is planned and not built.

Hasura points at databases and APIs you already have, many of them Dartvel has no adapter for, and gives you one API over all of them, including ones nobody wants to rewrite.

Its subscriptions are a documented client path today. Dartvel's generated data models do not yet sync changes to devices on their own.

GraphQL is a standard with a large ecosystem of clients in every language. Dartvel's generated client is Dart only, and its GraphQL endpoint covers data models and not federation.

Hasura DDN is a running hosted product. Dartvel Cloud is not open yet.

Federating several databases and services behind one supergraph is Hasura's job and not Dartvel's.

These are not the same kind of tool. Hasura is an API layer over data you already have; Dartvel is the whole application. The comparison is worth making because a Flutter team choosing Hasura is often choosing it for typed data access from the app, and that is a thing Dartvel gives them without a query language.

Hasura for Flutter, without the query language in the middle.

The same jobs, done differently.

Both keep the rules in the repository.

Where Hasura is ahead today.

Dartvel next to the tools people ask about.