Dartvel v0.3.0

Four queue brokers verified against real services, TLS on both network databases, block-bodied pages, static generation that produces pages, and crawler-visible HTML built from the semantics tree.

Queues, on real brokers

Seven adapters: in-memory, database, Redis, SQS, RabbitMQ, Pub/Sub and Kafka. The four that talk to a network service are verified in CI against the real thing — ElasticMQ, RabbitMQ's own image, Google's emulator and Apache Kafka — rather than against a fake that agrees with whatever the adapter does.

That found nine bugs which every unit test had passed, among them a backoff sent as an initial delay, delivery-mode written to the wrong bit, a Fetch reply parsed with three fewer fields than it has, and a payloadType that would have stopped every handler from matching.

Each adapter is written around what its service offers rather than over it. SQS and Pub/Sub refuse pending instead of returning an empty list, because an empty list reads as "there is nothing" when the truth is "I cannot see". Kafka is a log, so it has no dead letters, no priority and no out-of-order retry, and lag gives a distance rather than a list.

Databases

PostgreSQL and MySQL negotiate TLS, which is what a managed endpoint requires — Aurora, Neon, Supabase, PlanetScale and Cloud SQL all demand it and most refuse plaintext, so the adapters previously reached localhost and nothing else. sslMode takes libpq's names, so a connection string from a provider's console pastes in unchanged. A refusal is fatal at require and above, because falling back would put the password on the wire in the clear while the caller believed otherwise.

Pages can have bodies

A private @DVPage input had to be a single expression, so every page needing a local, a loop or a condition was written as a one-line wrapper around a public helper. Block bodies are lowered into the generated widget now. @DVFunctionalWidget and @DVBackendFunction still require expression bodies.

Static generation

dartvel build web writes a page per route and expands parameterised routes through the application's own resolvers. @DVModel(generatePublicPages: true) now generates the route as well as the paths — it previously produced a list of addresses that all resolved to the application's own not-found page. A page no route serves is refused rather than written.

The web output

Crawler-visible HTML is built from the page's semantics tree rather than from string literals in the source, so it carries real headings, anchors and landmarks instead of one paragraph per source line. Pages gained structured data, a stylesheet for sitemap.xml, and the .htaccess that path URLs need and that nothing was writing. In-app links push the route instead of tearing the document down and rebuilding the whole application.

Versions

dartvel_cli, dartvel_core, dartvel_dev and dartvel_flutter at 0.3.0; dartvel_shelf at 0.4.0; dartvel_generator at 1.1.0. The npm launcher tracks the CLI.