320x100 Projects/NPE4 빠른 대응을 위한 실시간 모니터링/알림 툴 도입 이번에 EAI_AGAIN 에러를 겪으면서 느낀 점은, 트래픽이 많지 않더라도 얼마든지 서버가 내려갈 수 있고, 제대로 세팅을 해놓지 않으면 최악의 경우에는 이를 눈치채지 못할 수도 있다는 점이다. 애초에 서버가 내려가지 않도록 하는게 가장 중요하지만, 항상 정말 예상치 못한 곳에서 문제가 발생하기 때문에 서버가 내려갔을 경우를 항상 대비해야 한다. 이를 위해 존재하는것이 다양한 모니터링 도구들이다. 기존에 나는 pm2를 통해 백엔드 서버 상태를 관리했었다. 도커 내에서 pm2를 통해 서버를 돌리게 되면 pm2 웹사이트에서 모니터링 툴을 제공해준다. 처음에는 이것만 해놓고 상당히 만족하고 있었다. 실시간으로 서버의 상태를 확인할 수 있고, 서버가 내려가면 버튼 눌러서 다시 서버를 재시작할수 있기 때문이다... 2022. 1. 7. TypeDI를 통한 의존관계 주입과 관심사의 분리 기존 구조와 문제점 현재 내 프로젝트에서, 백엔드 구조는 다음과 같다. 현재 Graphql 을 사용하고 있고, 외부에서 요청이 들어오면 이를 Resolver에서 받아서 알맞는 Service 로직을 호출한다. (REST API 에서 Controller의 역할을 한다) 이후에 Service 로직에서는 비즈니스 로직을 수행하고 필요한 데이터를 얻기 위해 Repository에 접근하며, Repository에서는 DB에 접근한다. 지금은 수정된지 오래되어 꽤 오래전 코드지만, 처음에는 이렇게 구현되어 있었다. UserService에서는 의존하고 있는 UserRepository를 그냥 Import 해서 Static 으로 사용한다(당시에는 TypeORM의 Data Mapper 대신 Active Record 패턴을 사.. 2021. 11. 29. [GraphQL] Typescript+GraphQl+TypeORM 프로젝트에 TypeGraphQL 적용하기 프로젝트를 진행하면서, 이번에 처음으로 Graphql 및 Typescript 를 도입해보게 되었다. 일단 Grahpql에 대한 첫인상은 매우좋음 이었다. 먼저 Graphql에서 쿼리를 요청하는 방식은 다음과 같다. 이런식으로 원하는 유저의 id 값, 유저명, 프로필 url 등을 원하는 값들만 클라이언트에서 선택해서 가져올 수 있다. 기존의 REST 방식의 Overfetching, Underfetching 문제를 해결한 완전한 방식인 것 같았다. 그런데 서버쪽 코드를 작성하면서 점점 느낌이 싸해졌다. 일단 현재 백엔드 구조는 이렇다. entity 디렉토리는 DB의 TypeORM엔티티들을 가지고 있다. 여기서 graphql 디렉토리는 다음과 같은 구조를 가지고 있다. inputTypes : Mutation .. 2021. 11. 8. [TypeORM] 쿼리빌더를 통해 데이터 가져오기 현재상황과 문제 먼저, 진행하고 있는 프로젝트에서 graphql 쿼리를 작성하기 위해 하나의 질문글에 달린 태그를 가져와야 한다. 먼저 필요한 테이블들의 관계는 다음과 같다. post_question과 tag가 N:M 관계를 가지고 있고, 연결 테이블로 question_tags 를 가지고 있다. graphql 질문글 검색 쿼리는 다음과 같은 상황이다. post_questions 요청을 통해 검색할 태그 ID 배열을 넘겨주고, 질문글의 제목과, 할당되어있는 태그들을 가져오는 쿼리를 작성한 모습이다. 요구사항은 간단한데 처음에 생각보다 구현에 급급하여 코드를 날림으로 작성해놓았다. 먼저 다른 조건들(whereObj)을 통해 해당하는 게시글들을 불러오고, tagID 가 검색 쿼리에 포함되어있다면 불러온 질문글.. 2021. 11. 7. 이전 1 다음
