320x100 Projects38 빠른 대응을 위한 실시간 모니터링/알림 툴 도입 이번에 EAI_AGAIN 에러를 겪으면서 느낀 점은, 트래픽이 많지 않더라도 얼마든지 서버가 내려갈 수 있고, 제대로 세팅을 해놓지 않으면 최악의 경우에는 이를 눈치채지 못할 수도 있다는 점이다. 애초에 서버가 내려가지 않도록 하는게 가장 중요하지만, 항상 정말 예상치 못한 곳에서 문제가 발생하기 때문에 서버가 내려갔을 경우를 항상 대비해야 한다. 이를 위해 존재하는것이 다양한 모니터링 도구들이다. 기존에 나는 pm2를 통해 백엔드 서버 상태를 관리했었다. 도커 내에서 pm2를 통해 서버를 돌리게 되면 pm2 웹사이트에서 모니터링 툴을 제공해준다. 처음에는 이것만 해놓고 상당히 만족하고 있었다. 실시간으로 서버의 상태를 확인할 수 있고, 서버가 내려가면 버튼 눌러서 다시 서버를 재시작할수 있기 때문이다... 2022. 1. 7. 프로젝트 개선사항 및 앞으로의 과제들 부스트캠프를 마치고 이전에 내가 했던 프로젝트를 둘러보았다. 그중 맛집찾아 프로젝트를 다시 보았는데.. 1년전 그당시 정말 처음 개발했던 때였지만 진짜 색도 그렇고 너무 처참한 뷰와 백엔드를 가지고 있었기에 이를 무조건 개선해야겠다고 생각했다. 내가 개선해야겠다고 생각한 사항들을 정리해서 README에 먼저 적어놓았다. 뷰 개선 가장 먼저 해야할 것은 뷰를 개선하는 것이다. 기존에는 스프링에서 Mustache를 사용하여 서버사이드에서 렌더링하고 있었는데, SPA인만큼 프론트에서 React를 사용해보고 싶었다. 이에 더하여 이제부터는 프론트든 백엔드든 기본적으로 Typescript를 적용하려고 한다. 기존 색배열이 너무 별로여서 아예 색을 흰색 + 회색 + 검정색으로 통일시켜서 Figma를 통해 그려보았다.. 2022. 1. 4. 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. 이전 1 2 3 4 ··· 10 다음
