# Alosaur: An MVC Web Framework for Deno Built on ES Decorators

> Alosaur is a MIT licensed TypeScript framework for Deno that organises an application into areas, controllers and actions, with dependency injection, lifecycle hooks and a security context for sessions and authorization. It suits developers who want decorator-driven routing without leaving the Deno runtime.

**alosaur/alosaur** — Alosaur - Deno web framework with many ES Decorators

- Repository: https://github.com/alosaur/alosaur
- Website: https://alosaur.github.io/info/
- Stars: 816 · Forks: 45
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/alosaur-alosaur

## Areas, controllers and the decorator on the route

Alosaur is a web framework for Deno, and its unit of organisation is the area. The framework's own vocabulary lists areas as the modules of your application, controllers as responsible for controlling the flow of application execution, and middleware as a mechanism for filtering HTTP requests entering the application. A controller is a class with a decorator on it, and each action is a method with its own decorator, so the route table is expressed in the type definitions rather than in a separate configuration file. The readme's example shows the smallest possible shape: a `@Controller()` decorated class with a `@Get()` decorated method, registered into a `@Area` decorator that names the controllers it contains, and an `App` constructed with that list of areas.

## The whole hello world, and how you run it

The readme's example is short enough to read in one go, and it shows the whole wiring of a framework: the import of `App`, `Area`, `Controller` and `Get`, a controller class, an area class that registers the controller, an application object constructed with the areas, and a call to start listening.

```typescript
import { App, Area, Controller, Get } from "https://deno.land/x/alosaur/mod.ts";
```

```bash
deno run --allow-net app.ts
```

The import is a URL, not a package name, which is the usual Deno convention and means the dependency is fetched by the runtime from the deno.land x module path. The run command asks for network permission only, with `--allow-net`, which is consistent with a framework that needs nothing else to serve HTTP. The repository root carries `mod.ts` as the entry point, along with `deno.json` for configuration, `cli.ts`, `imports.json`, and separate `lite.ts` and `security.ts` modules, so the imports in the example have a local counterpart in the source tree.

## Dependency injection by default, not by request

Alosaur lists dependency injection as applying to all controllers and hooks by default, and there is a dedicated example directory for it, plus another for custom DI, which suggests both the default behaviour and the extension point are meant to be used. The distinction matters because injection by default removes the decision: in a framework where you must annotate each class to get its dependencies resolved, teams tend to write their own container anyway, and the container becomes a second design centre. Here the framework states that controllers and hooks get it, and the presence of both a `di/` and a `customdi/` example implies you can supply your own resolution when the default does not fit. The examples directory also covers `db/`, which is how a data layer fits alongside an injected service, and `kv/` for key value storage.

## Hooks that wrap an action on three sides

Hooks are the framework's second middleware layer, described as middleware for area, controller and actions with support for dependency injection, and they have three life cycle functions: `onPreAction`, `onPostAction` and `onCatchAction`. That shape is the familiar one from action filters, with the addition that a hook can be scoped to an area, a controller or a single action, which means a global error handler, a per-controller logger and a single endpoint override are all expressed the same way. The `onCatchAction` step is the interesting one, because it is where an exception becomes a response, and the security module depends on that kind of interception to turn an unauthenticated request into a challenge. The `hooks/` example directory is where to look for how the three functions are used together.

## Security as a context rather than a set of middlewares

The security support is described as a security context covering session, authentication, authorization, OAuth, Google and custom strategy, and the source lives in a dedicated `src/security` directory with a `security.ts` module at the repository root. Modelling this as a context rather than as a stack of middlewares is the design choice worth understanding, because it means an action can ask who the caller is instead of the framework rejecting the request before it arrives. Custom strategy is listed alongside the built-in ones, so a team with an existing identity provider can plug it in rather than reimplementing OAuth. The `auth/` example directory covers usage, and the `openapi/` directory at the root suggests the framework also generates or consumes an OpenAPI description.

## What the examples directory says about the framework's reach

The examples are the most informative part of the repository, and their names describe the feature surface better than the readme does. There are `angular/` and `react/` and `spa/` for single page applications, `sse/` for server sent events and `ws/` for websockets, `cache/` and `kv/` for storage layers, `cors/` for cross origin handling, `validator/` for input validation, `form-data/` for multipart handling, `static/` for serving files, `middleware/` and `hooks/` for the request pipeline, `customdi/` and `di/` for dependency injection, `db/` for databases, `microservice/` for service to service setups, `eta/` and `handlebars/` for template rendering, `docker/` for packaging, `default/` and `basic/` for starting points, and `_utils/` for shared helpers. The presence of `angular/` alongside `react/` is unusual and suggests the framework is tested against real single page applications rather than a toy front end.

## Version 2, a lite build, and where the activity is

The release history shows a big jump and then a long gap. Version 1.1.0 came on 2024-02-23 and 1.1.1 on 2024-03-03, then v2.0.0 on 2026-07-16, with the last push on 2026-07-24. That gap between the 1.x line and the 2.0 release is over two years, so anyone adopting this now starts from a recent major version with an API whose shape you cannot infer from the older releases. The repository also has a CHANGELOG.md and a CONTRIBUTION.md, so the details of the version 2 changes are recorded rather than only implied. For Deno Deploy specifically, the readme directs you to a separate lightweight version of the framework, Alosaur Lite.

## Conclusion

Alosaur fits a Deno developer who wants the areas and controllers structure of an MVC framework with dependency injection already wired in, and who is comfortable with ES decorators in the codebase. It is the wrong choice if your runtime is Node, or if you want a framework that runs unchanged on Deno Deploy, since the project points you at a separate lightweight build for that. Before adopting it, read the examples directory rather than the readme, because the readme only shows the hello world route while the examples cover caching, CORS, validation and websockets.

## FAQ

### How do I create and run a Deno app with Alosaur?

Decorate a class with @Controller, give a method a @Get, register the controller in an @Area, construct an App with the areas and call app.listen(). The file is then served with deno run --allow-net app.ts.

### Does Alosaur support dependency injection?

Yes, and it is enabled by default for all controllers and hooks. The examples directory includes both a di/ example for the default behaviour and a customdi/ example for supplying your own resolution.

### What can Alosaur hooks do?

Hooks are middleware scoped to an area, a controller or an action, with dependency injection support, and they have three life cycle functions: onPreAction, onPostAction and onCatchAction.

### How does Alosaur handle authentication and sessions?

Security is implemented as a security context covering session, authentication, authorization, OAuth, Google and custom strategy, with the source in the src/security directory and a security.ts module at the repository root.

### Can I run Alosaur on Deno Deploy?

The project points you to a separate lightweight build for that, Alosaur Lite.

## Sources

- [alosaur/alosaur on GitHub](https://github.com/alosaur/alosaur)
- [License: MIT](https://github.com/alosaur/alosaur/blob/master/LICENSE)
- [Project website](https://alosaur.github.io/info/)
- [README](https://github.com/alosaur/alosaur/blob/master/README.md)
- [Releases](https://github.com/alosaur/alosaur/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/alosaur-alosaur