biud436 / blog-api-server

🔥 This project is the blog server that is made with the server framework called Nest.js

🧳 Github Stats

🔨 Tech Stack

Backend: NestJS, Node.js, TypeORM, Docker, Redis, AWS EC2, Linux(Ubuntu)

Database: MariaDB

Frontend: React, React Native, SWR, React Query, Styled Components, MUI

Languages: Typescript, Javascript, Ruby, C#, C++

blog-api-server's Issues

Orm 설정 모듈에 TypeOrmModule.forFeature 설정하기

TypeOrmModule을 단독으로 import 할 경우 정적인 모듈이라 로드 순서가 빨라 providers 배열과 exports 배열이 비어있어 DI 오류가 발생한다.

하지만 아래와 같이 하면 나중에 로드된 providers와 exrpots의 정보가 TypeOrmModule에 담겨있게 된다.

따라서 모든 것이 제대로 임포트 된다.

@Module({
  imports: [
    TypeOrmModule.forFeature([
      AdminRepository,
      PostRepository,
      ProfileRepository,
      UserRepository,
    ]),
  ],
  exports: [TypeOrmModule],
})
export class OrmModule {}

아니면 아래와 같은 식으로 할 수도 있다.

export const dynamicOrmModule = TypeOrmModule.forFeature([
  AdminRepository,
  PostRepository,
  ProfileRepository,
  UserRepository,
]);

fix: 트랜잭션 rollback에 error 매개변수 추가

비공개 포스트 기능 추가

feat: restore swagger decorators

Nes*ia를 사용하면서 OpenAPI (Swagger) 관련 데코레이터를 전부 제거하였다.

편의성은 상당히 올라갔고 복잡한 타입에 대한 설명을 하는 데코레이터 작성을 할 필요가 없기 때문에 코드가 깔끔해졌다.

하지만 테스트 수행을 테스트 코드나 포스트맨이 아닌, 미개하지만 스웨거를 통해 테스트 하고 있는 나의 입장에서는 API를 하나 만들고 문서를 다시 빌드하는데 꽤 오랜 시간이 걸렸다 (분석 시간 소요) 즉, 하나를 수정해도 이 문서를 확인하기 위해 많은 시간을 기다려야 했다.

테스트 방법이 달라지지 않는 한, Nes*ia를 사용하더라도, OpenAPI (Swagger) 관련 데코레이터를 다시 추가하는 것이 나을 것으로 보여진다.

feat: `@Commit`, `@BeforeTransaction`, `@AfterTransaction`, `@Rollback` 추가

이미 구현된 거라 네스트로 옮기기만 하면 됩니다.

biud436/stingerloom#30

자세한 내용은 위 링크를 참고하세요.

컴파일러를 SWC로 변경할 것

새로 공식 문서에 올라온 문서에 의하면 러스트 기반인 SWC로 번들 파일을 할 수 있는 것으로 드러났습니다.

https://docs.nestjs.com/recipes/swc

TypeORM 순환참조 부분을 유의하면서 적용을 해야할 것 같습니다.

적용 시, 프로덕션 모드에서 빌드가 최대 20배 빨라진다고 하며 최종 빌드 속도도 역시 약간 줄어들 것으로 생각됩니다.

노드 모듈 종속성 때문에 yarn berry를 적용하지 않는 이상, 크게 줄일 수는 없지만 그래도 더 나은 길로 보여집니다.

블로그에 우선 적용해보고 괜찮으면 실무에도 반영할 것입니다.

편두통 및 각종 증상 기록하는 캘린더 앱으로로 변경

블로그는 너무 흔해 실용성이 없으며,

증상명, 증상을 상세 기록하는 캘린더 서버로 변경할 것.

프로젝트 명도 변경 필요.

나에게 필요한 프로젝트로 변경할 것.

프론트는 모바일에 초점을 맞출 것.

Remove Swagger Docs

We will be going to add JSDoc style comments above a method in server class. Because the swagger decorator has to use so many decorators on above the methods in controller. There is an alternative like Nestia in the NestJS. BUT this library is hard to use, however it is so awesome.

ConnectionInfo에 도커 내부 IP 가 입력되는 문제

• Nginx 설정 변경 필요

https://serverfault.com/a/778894

`/posts` 를 `/post`로 변경하기

RESTful API를 설계할 때, 정말 많은 API가 만들어지게 되는데 이때 어쩔 수 없이 RESTful 원칙을 어길 수 밖에 없는 경우가 상당히 많다.

김영한의 HTTP 강좌에서도 그러하듯, 나 역시도 실무에서 RESTful 원칙을 지킬 수 없는 경우가 상당하게 있었다.

하지만, 처음에 /posts라고 정한 건, 웹과 관련된 컨트롤러에도 Post가 있고, ORM과 관련된 Entity에도 Post가 있어서 두 개의 PostModule이 탄생하기 때문에 s를 붙여서 PostsModule이라고 정한 것에서 시작된다.

React에서도 이렇게 주소가 빈번하게 바뀔 것을 예상했기 때문에 URL을 따로 매핑해뒀었다. 하지만 URL을 맵핑하는 기능이 상당히 지저분했기 때문에, 이러한 원칙을 철저하게 지킨 것은 아니었다.

원칙을 철저하게 지켜 코딩을 했었다면 변환 작업이 더욱 쉬웠을 것이다. 원칙을 제대로 지키지 않아 React 상에서 하드코딩된 URL 요소들을 찾기로 찾아서 변환을 시작해야 한다.

서버의 경우, PostsModule 모듈을 굳이 PostModule 모듈로 바꿀 필요는 없다. 이때, 네임스페이스 등을 활용하면 충돌을 방지할 수 있지만, 자칫 잘못하면 협업에 문제를 일으킬 수 있으므로 이러한 스타일을 최대한 배제하였다.

컨트롤러에서 /post 접근도 같이 제공하고, 프론트엔드에서 URL 맵핑을 다시 한 후, 사이트맵을 다시 제출하고 반영되면 /posts를 제거하는 것이 좋다고 판단된다.

하지만 이미 구글 서치 엔진에 노출된 posts 때문에, 이제와서 제거하는 것은 늦었다는 생각이 들기도 한다. 한 가지 방법으로는 NGINX 에서 정규표현식을 이용하여 posts에서 post로 바꿔서 보내는 방법도 있을 것 같다는 생각이 든다.

feat: 댓글 삭제 기능 추가

댓글 삭제 시, TypeOrm의 DeleteDateColumn 및 softDelete와 유사한 상태를 구현해야 한다. 답글이 달려있을 경우에는 댓글이 삭제되었습니다를 띄워서 softDelete와 유사하게 해야 하고 답글(자식)이 없을 땐 실제로 삭제 처리를 해야한다. 자식이 있을 때에도 실제 삭제 처리를 할 수도 있지만 이렇게 하면, 이후에 달린 모든 댓글의 pos 와 depth 값을 전부 업데이트 해야 하므로 성능에 좋지 않을 수 있다. 또한 댓글이 1000개, 10000개 달렸을 경우 10000개를 업데이트 해야 한다는 계산이 나오게 된다. 따라서 실제 삭제를 하지 않는다.

반면 자식이 없을 땐 실제 삭제 처리를 해도 무방하다.

SWC로 변경한 후, S3 이미지 업로드 처리가 되지 않음

아직 자세하게 살펴보지 못했지만 자동 이미지 업로드가 되지 않고 없었던 CORS 오류가 나오고 있습니다. 서버 설정 상으로는 CORS 오류가 날 일이 없습니다. 의심 가는 점은 최근에 컴파일러를 SWC로 바꾸면서 타입 유형을 더 강화했다는 점입니다.

multer-s3 이 부분의 타입 유형에 오류가 나, 버전 등을 조정한 바 있습니다.

blog-api-server/backend/src/common/interceptors/s3.upload.interceptor.ts

Line 19 in f6295cc

import multerS3 from 'multer-s3';

해당 코드는 위와 같으며 SWC 설정 때문에 CommonJS 방식의 라이브러리를 위와 같이 불러온 것이 전부입니다. 즉, esModuleInterop이 적용된 것과 동일하게 되었습니다.

따라서 import * as multerS3 from "multer-s3" 에서 import multerS3 from "multer-s3"로 변경하고 컴파일러 오류를 해결하였습니다. 하지만 이 코드 변경 하나로 생긴 문제인지는 현재 확실하지 않습니다.

이 부분, 테스트가 필요할 것으로 보여집니다.

if the certain post is not exist, nevertheless the server didn't cause the error.

I will fix this issue, I think that this has critical security issue.

Dependencies

• Redis : The Redis allows you to get the count the view of the certain post,
• TypeORM
• Nest.js (Node.js)
• High Traffic

TODO: handle the rss using redis cache between blue and green servers.

TODO

• Reads 20 posts (that means the maximum value is to 20) and then create a virtual xml file using node-rss module in memory
• Sets up the CacheModule that is injected redis and ConfigService
• Needs to return the same as value using cache across two servers (blue and green)

Dependency

• redis@^4

Reference

caching

`typeorm`의 QueryBuilder에 setPagination 함수 추가

PaginationConfig 설정으로부터 정해진 config를 수행합니다.

SelectQueryBuilder.prototype.setPagination = function (
    this: SelectQueryBuilder<any>,
    pageNumber?: number,
) {
    if (this.expressionMap.joinAttributes.length > 0) {
        console.warn(
            '조인이 설정된 경우, setPagination이 제대로 동작하지 않을 수 있습니다. setPaginationWithJoin를 사용해주세요.',
        );
    }
    this.offset(PaginationConfig.limit.pagePerNumber * pageNumber).limit(
        PaginationConfig.limit.pagePerNumber,
    );

    return this;
};

SelectQueryBuilder.prototype.setPaginationWithJoin = function (
    this: SelectQueryBuilder<any>,
    pageNumber?: number,
) {
    this.skip(PaginationConfig.limit.pagePerNumber * pageNumber).take(
        PaginationConfig.limit.pagePerNumber,
    );

    return this;
};

`나만 보기` 기능 추가

feat: added feature that can inject a queryRunner in the route of controller

컨트롤러의 핸들러 값을 대체하려면 descripter.value를 대체해야 합니다.

다만 descripter.value를 대체하면 프로토타입에 마킹된 메타데이터가 증발하는 문제가 있습니다.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/setPrototypeOf

위 함수를 이용하여 기존에 마킹된 메타데이터 값을 복구해줘야 합니다.

여기까진 제대로 진행했으나, QueryRunner가 매개변수로 주입이 되지 않는 문제가 있었습니다.

회원 가입 및 인증 절차 추가할 것

도커로 테스트 후, 추가할 것.

refactor: transaction consumer로 책임 분리하기

AES256Provider Issue

onModuleInit는 위상 정렬에 따라 호출되기 때문에, onModuleInit() 안에서 멤버 변수를 초기화하면 일부 데이터가 초기 램덤값으로 암호화가 되는 현상이 있다.

이 문제를 해결하려면 생성자로 옮겨줘야 한다.

AES-256 모듈을 추가할 것

refactor: 트랜잭션 데코레이터로 정리

반복되는 트랜잭션 처리를 위하여 @Transactional 데코레이터를 만들었습니다.

하지만 일부 코드에서만 활용하고 있어서 전반적인 리팩토링이 필요합니다.

uuid v4 발급 테스트

AES-256 Provider에서 KEY와 IV 발급 시 필요합니다.

AWS SES로 이메일 전송하기 [테스트 코드 작성]

feat: 댓글 펼침 / 댓글 접힘 댓글 보기 API 추가

추가 필요

SelectQueryBuilder<Entity>를 prototype로 개작하면 Nestia에서 Type을 찾지 못함

기존 코드 유지를 위한 코어 분석

TypeORM의 코어를 분석해보면 SelectQueryBuilder는 EntityManager 등으로부터 생성되며 유저가 상속 등을 통해 개작하는 것은 불가능하다. 트릭으로 prototype을 사용하면 가능했지만, Nestia(컴파일러 수준)에서 타입을 찾지 못하므로 SelectQueryBuilder에 부착했던 기능들을 다음과 같이 마이그레이션하기로 하였다.

@Injectable()
export class PaginationProvider {
    setPagination<Entity extends ObjectLiteral>(
        queryBuilder: SelectQueryBuilder<Entity>,
        pageNumber?: number,
        numberPerPage?: number,
    ) {
        numberPerPage ??= PaginationConfig.limit.numberPerPage;

        if (!pageNumber) {
            pageNumber = 1;
        }

        if (pageNumber < 1) {
            pageNumber = 1;
        }

        queryBuilder
            .offset(numberPerPage * (pageNumber - 1))
            .limit(numberPerPage);

        return this;
    }

위 프로바이더 클래스로 DI하여 우회할 예정이다.

3시간의 코드 튜닝

사용하기 쉽다고 적혀있지만, 그건 만든 사람의 입장이고, 나같은 초보자(?)들은 기존 프로젝트에 적용하는 것 조차 쉽지 않았다.

필자는 네스티아를 사용하기 위해서 3시간 가까이 코드를 튜닝했다. 오류가 너무 많았기 때문이다. 기본적으로 컴파일러 설정이 네스트에서 생성하는 기본 프로젝트와 달라진다. 셋업 후에 새로운 옵션이 추가되기 때문이다.

엄격한 타입을 지켜야하는 strict가 설정되어있고, 또한 컴파일러를 통해 감지할 수 없는 런타임 메타 데이터 등은 인식하지 못해서 애를 먹었다.

예를 들면, 네스트 프로바이더에서 useClass로 전달되는 타입들은 런타임에서나 가능한거라 컴파일 타임에는 당연히 인식하지 못했다. 이러한 동작 방식의 차이를 알고 나면, 오류가 예측되기에 이른다.

모든 오류 제거 끝에 구동은 성공했지만 지난 시도에서 오류를 겪은 메소드에서 다시 오류가 발생하여 1시간 추적 끝에 문제를 알아내고 해결했다.

스웨거 문서 빌드 오류

이러한 끝없는 오류 제거 과정을 통해, 스웨거 빌드를 하는 순간, 분명 아무런 문제 없이 실행되었던 prototype를 사용한 개작 코드에서 타입을 알 수 없다는 문제를 겪었다. 추가 타입을 인터페이스에 정의하였기 때문에 서버 시작 시, 오류는 없지만 문서 빌드 시에는 알 수 없다는 오류를 내뿜었다.

결론

평소에 타입스크립트 코딩 스타일이 엄격한 타입을 명시하고, 컴파일러의 동작을 염두하고 코드를 짰다면 도입하기 수월할 것이다. 그러나 필자처럼 그저 nest cli를 통해 프로젝트를 만들고 공식 문서와 해외 블로그 문서등을 통해 이것저것 추가한 경우라면 컴파일 타임에 동작하는 방식의 차이로 인해 수 많은 오류를 만나게 된다.

이것을 도입하기 위해 과감하게 비록 비루한 개인 블로그 프로젝트임에도 불구하고 스웨거 데코레이터를 없애버렸는데, 스웨거 문서 빌드 시 오류가 다 없어지는 그날까지 코드를 계속 손봐야 할 듯 싶다.

깃허브 로그인