tinka alpha
tinkaalpha

Roadmap

Tinka grows one package at a time, and each one ships with its tests and its docs page, or it does not ship. The foundation is done: the Introduction lists what an App can use today, and Releases records what each version holds. This page lists what comes next.

The roadmap has no dates. A package is ready when it is complete, tested and documented, and its API settles before v1.0.0.

Planned packages

Validation

Typed validation of request bodies, query strings and route params, with every failing field reported together in one problem details response. The body parser already decodes bodies into typed values and accepts a validator, so validation builds on what handlers do today.

Sessions and authentication

Sessions that keep state between requests, logging users in and out, guards that protect routes, and authorization checks that decide what a signed-in user may do. Passwords already hash with Argon2id, and cookies are signed and encrypted with the App's key.

Data layer

Access to SQL databases, migrations that evolve the schema with the App, and models for reading and writing rows. Until it ships, open a database with database/sql and register the pool in a service provider, as the FAQs show.

HTTP security

A static file server with caching headers, CORS for APIs that browsers call from other origins, CSRF protection for forms, and rate limiting. Today app.Handle serves files with the standard library's http.FileServerFS, as Routing shows, and net/http middleware already runs in Tinka's chain through tinka.Std, so you can add a package you trust in the meantime: see Middleware.

Left out on purpose

Some things Tinka does not plan to add, because the language or the principles already answer them:

See also: Releases, Philosophy, Contributing