Odi - 서버 측 프레임워크

소개

안녕하세요!
현재 서버 측 TypeScript 프레임워크를 개발 중입니다.우리 팀은 이미 각종 전자상거래와 ERP 프로젝트에서 이 프레임워크를 광범위하게 사용했다.구조와 의미는 다른 유행 틀의 계발을 받았다. 예를 들어 Spring와ASP.NET.
주요 대상 목록:

테스트, 지원, 확장

간결하고 깔끔하며 또렷함

직관적이고 읽기 쉽고 알기 쉽게

강력함

​
현재로서는 여러 가지 가능성이 있다.

컨트롤러와 장식기를 사용하는 경로 설명

강력한 모든 유형 의존 주입

각종 장식기

를 사용하여 전송된 데이터 확인(AJV 사용)

TypeORM 통합(라이브러리 주입, CLS 사용 트랜잭션 지원)

JWT 기반 확장 인증

프레임워크의 모든 부분은 전체 유형이고 전체 인프라 시설과 통합된다.
최상의 성능을 얻기 위해 엔진 덮개 아래에서 사용Fastify.이 프레임워크는 성명적이지만 가능한 경우decorator를 사용하지 않습니다.그래서 모든 것을 간단하고 깨끗하며 간략하게 유지한다.

개요

컨트롤러

컨트롤러는 간단한 스타일을 간단하고 강력한 루트 메커니즘으로 한다.

    @Controller('foo') 
    export class FooController extends IController {      

        @RoutePatch('{id}')     
        bar(id: string, payload: FooDTO) {         
            ...some updates..          
            return Ok();     
        } 

        @Get index() {
            return 'Foo';
        }
    } 

따라서 보시다시피 HTTP에서 요청한 주입 데이터에 추가 인자 수식자를 제공할 필요가 없습니다.이것은 단지 작은 컨트롤러의 개술일 뿐, 아직 많은 다른 가능성이 있다.docs 에서 더 많은 정보를 읽을 수 있습니다.

의존 주입

Odi는 강력한 기존 의존 주입 메커니즘을 가지고 있다.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;
        }​
    } 

보시다시피 모든 의존 항목은 모든 응용 프로그램 구성 요소에 자동으로 제공됩니다.
현재 Odi는 다음과 같은 3가지 주입 방식을 지원합니다.

건설업자

가 제공

재산별

통과 방법

Odi 구성 요소가 아닌 클래스는 DI에 참여할 수 있습니다.미리 설정된 속성과 구조 함수 파라미터를 사용하여 동작을 간단하게 정의할 수 있습니다.

    class Pet {
        ...
    }

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

DTO 회사

웹 서버가 데이터를 처리하기 전에 데이터를 검증해야 할 때 이것은 흔히 볼 수 있는 장면이다.DTO는 이 프로세스를 최적화하고 자동화할 수 있습니다.

    @Data()
    export class TodoDTO {
​
        @MaxLength(80)
        title: string;
​
        @IsOptional()
        @MaxLength(255)
        desctiption: string;

}

그런 다음 디렉터 메서드의 매개 변수로 DTO 클래스를 추가해야 합니다.

    @Controller('todo')
    export class TodoController extends IController {

        @Autowired()
        todoService: TodoService;   

        @Post async index(payload: TodoDTO) {
            ...
        }​
    }

이렇게!Odi는 인증된 요청체를 이 매개변수에 자동으로 주입합니다.검증 과정에서 오류가 발생하면 400개의 상태 코드와 오류 설명을 보냅니다.
Odi는 중첩된 DTO, 배열, 매거 등을 지원하는 광범위한 DTO 설명 집합을 제공합니다.

종합하여 서술하다.

이것은 일부 기능의 작은 개술이다.자세한 내용을 보려면 Docs 을 참조하십시오.

곧 올 것이다

AOP

GRPC 통합

GraphQL

CLI

OpenAPI

그 이상...

링크

Odi ts / 아우디

🌪🌌 확장 가능하고 지원 가능하며 신뢰할 수 있는 기업 응용 프로그램을 구축하는 데 사용되는 독선적이고 성명적이며 관용적인 프레임워크입니다.

TypeScript 프레임워크는 간단하고 가장 낮은 API를 가진 기업급 (웹) 응용 프로그램을 만드는 데 사용되며, 업무 논리에 전념할 수 있습니다.성명식과 명령식 프로그래밍을 바탕으로 ASP.NET/Spring의 계발을 받았다.
자세한 내용은 Docs 를 참조하십시오.
Odi는 지원되고 확장 가능한 웹 응용 프로그램을 만드는 데 사용할 수 있는 기능 집합을 제공합니다.
기능 개요:
MVC전체 유형 DI/IoT인증 WebSocketsTypeform 통합GraphQLAOPSSR향후 업데이트 점검 Roadmap
아이디어, 제안 또는 기능 요구가 있습니까?마음대로 Submit 하세요!

🚀 입문

npm 패키지 설치npm install odi --save

반사 메타데이터 설치npm install reflect-metadata --save

반사 메타데이터 가져오기(예:index.ts

import "reflect-metadata"; 에서 다음 설정을 사용합니다.
“emitDecoratorMetadata”:true,
"실험 Decorators": 정확함

🌪 개요

컨트롤러

컨트롤러는 간단한 스타일을 간단하고 강력한 루트 메커니즘으로 한다.
@ 컨트롤러("foo")
내보내기 클래스 FooController는 IController를 확장합니다. {...
View on GitHub
Docs
그 밖에 우리의 목표는 미래에 지원하는 것이다Deno.

Nestjs 간의 차이

기본적으로 Nestjs는 MVC 모드와 성명식 스타일의 몇 가지 공통점만 가지고 있다.그러나 전체 인프라 시설, 장식기 사용, 주입에 의존하는 것과 다른 점이 많다.차이점 요약:

Nestjs는 장식기를 대량으로 사용하는데 Odi는 이런 사용을 최소화한다(코드가 깨끗하고 읽을 수 있도록 유지한다).

Odi는 AJV를 통해 HTTP 데이터에 내장된 오픈 즉시 인증을 제공합니다.

DI/IoT는 매우 다릅니다.쉽게 말하면 아우디는 더 많은 마력을 가지고 있다:)

상자를 열면 바로 사용할 수 있는 신분 검증으로 다른 프레임워크 모듈과 완전히 통합된다.

컨트롤러 및 WebSocket 처리

미래에 이것은 모든 통합과 기술 간의 커다란 차이가 될 것이다. 왜냐하면 Odi는 처음부터 Nest가 아니라 다른 방식으로 설계되었기 때문이다.
내가 보기에 Nestjs는 Spring에 관한 것이 더 많지만 우리의 프레임워크는 ASP:)

붓을 대다

처음부터 이 프레임워크는 개원으로 설계되었다.나는 정말 너의 피드백이 필요하다. 이것은 나에게 매우 중요하다.

P、 P.S

내 고양이 낸시가 github에 별을 부탁한다😄😄