Odi

3 min readDec 29, 2018

Introduction

Hi guys!

I am currently working on the server-side TypeScript framework. My team already widely use this framework in various e-commerce and ERP projects. Structure and semantic were inspired by other popular frameworks like Spring and ASP.NET.

List of main goals:

Testable, supportable, scalable
Minimalistic, idiomatic, clear
Intuitive, readable, understandable
Powerful

Currently, there are a lot of possibilities:

Describing routing using controllers and decorators
Powerful, full-typed Dependency Injection
Incoming data validation (using AJV) with various set of decorators
TypeORM integration (Repositories injection, Transactional support using CLS)
Extendable JWT-based authentication

All parts of the framework are fully typed and integrated with the whole infrastructure.

For the best performance, under the hood, Fastify is used. The framework is declarative, but also avoids using decorators were it’s possible. So, it’s keep everything simple, clean and minimalistic.

Overview

Controller

Controllers serve as a simple yet powerful routing mechanism in a minimalistic style.

@Controller('foo') 
export class FooController extends IController {      
        
    @RoutePatch('{id}')     
    bar(id: string, payload: FooDTO) {         
        ...some updates..          
        return Ok();     
    }@Get index() {
        return 'Foo';
    }
}

So, as you see, there no need to provide any additional param decorators for injection data from the HTTP request. It’s just a small controller overview, there are a lot of other possibilities. You can read more in docs.

Dependency Injection

Odi has powerful dependency injection mechanism out of the box. (Let’s imagine that we already have FooRepository)

//foo.service.ts
@Service()
export class FooService {

    @Autowired()
    repository: FooRepository;

    public getFoo(id: string) {    
        return this.repository.findOne(id);
    }
}//foo.controller.ts
@Controller('foo')
export class OrderController extends IController {

    @Autowired()
    fooService: OrderService;

    @Get async '{id}' (id: string) {
        const foo = this.fooService.getFoo(id);
            
        if(!foo)
            return NotFound();return foo;
    }
}

As you can see, all dependencies will be automatically provided to all application components.

Currently, Odi supports 3 ways of injection:

By constructor
By property
By method

Classes that are not Odi components can participate in DI. You can simply define behaviour with preset properties and constructor args.

class Pet {
   ...
}define(Pet)
    .set('default', {
       constructorArgs: [...],        
       props: {...},
       type: 'singleton'
    })
    .set('special', {
       constructorArgs: [...],        
       props: {...},
       type: 'scoped'
    });

DTO

It’s a common scenario when the web server should validate data before processing. DTO can optimize and automate this process.

@Data()
export class TodoDTO {

    @MaxLength(80)
    title: string;

    @IsOptional()
    @MaxLength(255)
    esctiption: string;    
}

Then, DTO class should be added as an argument for the controller method

@Controller('todo')
export class TodoController extends IController {
    
    @Autowired()
    todoService: TodoService;   
         
    @Post async index(payload: TodoDTO) {
        ...
    }
}

And it’s all! Odi will automatically inject the validated request body in this argument. If there are some errors during validation, 400 status code will be sent with errors description.

Odi provides a wide set for DTO description, supporting nested DTOs, arrays, enums and etc.

To Sum up

It was a small overview of some features. If you interested in more, check the Docs.

Coming Soon

AOP
GRPC integration
GraphQL
CLI
OpenAPI
and more…

Links

Also, we aim to support Deno in the future.

Difference between Nestjs

Basically, there only a few common things with Nestjs: MVC Pattern and declarative style. But there are a lot of differences, like the whole infrastructure, decorators use, dependency injection and many others. To sum up differences:

Nestjs is heavily using decorators, Odi reduces this usage to the minimum (To keep code clean and readable).
Odi provides built-in validation out of the box for HTTP data via AJV.
DI/IoT behaviour is very different. There is much more magic in Odi, in few words :)
Authentication out of the box, that fully integrated with other framework modules.
Controller and WebSockets processing

In the future, it will be the big difference between all integrations and technologies, as Odi was designed from the beginning in another way than Nest.

In my sight, Nestjs is more about Spring, but our framework is more ASP :)

P.S

From the beginning, the framework was designed as opensource. I really need your feedback, it’s very important for me! Also, if you like the idea, leave the star in GitHub repo, please :)

Odi