기주 기주

SSE를 이용해서 알림기능 구현하기실시간으로 데이터를 업데이트 해야하는 경우에는 서버로부터 데이터를 받아와야한다.이때는 사용할 수 있는 기술로는1.Polling / Long Polling2.WebSocket 3.SSE와 같은 것들이 있다. Polling 기법클라이언트에서 서버로 주기적, 반복적으로 HTTP 요청을 보내는 것.주기적으로 요청을 보내다보면 만약 데이터에 변동사항이 생겼을 때 이를 확인하고 받아올 수 있음.요청하는데 부담이 크지않거나, 요청주기를 길게 잡아도 될만큼 실시간성이 중요하지않거나, 데이터 갱신이 특정 주기를 가질 때 적합하다. 장점:구현이 단순하다단점:Http Overhead 발생(계속 http 요청을 보내야하기 때문에 리소스 낭비가 발생한다. 요청 주기가 짧다면 http요청이 많아..

1. PAT(Personal Access Token) 발급 이때 토큰의 권한은 repo관련 모든 권한과 workflow 권한을 추가해둔다.토큰은 1번만 보여주므로 다른곳에 복사해둔다.   2. Repository 권한 설정workflow permission 섹션에서  read and write permission 활성화 (organization의 레포지토리인 경우 어드민 권한 필요할 수 있음)   3. deploy.yml 작성  1.Checkout repositoryactions/checkout@v3 액션을 사용하여 main 브랜치의 최신 코드를 self-hosted 서버로 가져옵니다. 이 단계에서 GITHUB_TOKEN을 사용해 인증이 이루어지며, 워크플로우가 리포지토리에 접근하여 코드를 복사합니다. ..

Refresh Token이 필요한 이유:JWT로 발급하는 토큰은 서버에 저장되지않고 발급된 토큰만으로 인증하는 방식이다.하지만 이러한 방식은 보안적인 부분에서 한계가 있다. JWT인증 방식의 한계1. 토큰 탈취 위험JWT는 서버에 저장되지 않기 때문에 만약 토큰이 탈취당한다면 대응할 방법이 없. 2. Access Token의 만료 시간 문제만료 시간을 길게 설정하면 탈취 당했을 때 악용될 가능성이 커진다.만료 시간을 짧게 설정하면 사용자가 로그인 요청을 자주 받아야하기 때문에 불편해진다. 이러한 문제들을 해결하고자 Refresh Token을 함께 이용하는 방식이 생겨났다.   Refresh Token의 역할1. Access Token 재발급:Refresh Token을 통해 짧은 만료 시간의 Access..

쿼리스트링으로 전달되는 값은 자동으로 문자열로 바뀌어 전달되게 된다. 그렇기 때문에 쿼리스트링에는 별도의 문자열 표시인 따옴표 ''를 쓰면 안된다. 이 따옴표 까지 문자열의 일부로 인식되기 때문에 원하는 결과를 얻지 못하게 될 수 있다.   예시) 관심사에 '여행'이라는 문자열이 들어간 데이터들을 찾아본다고 가정하자    1.  {{baseUrl}}/user?search='여행'따옴표 까지 문자열의 일부로 인식되어 원하는 데이터 검색이 안된다.        2.  {{baseUrl}}/user?search=여행->  따옴표가 없어도 문자열로 변환되어 '여행' 값이 들어간 데이터가 검색된다        결론쿼리스트링에는 따옴표를 넣으면 안된다

오버라이딩:메소드 재정의상속으로 인해 동일한 이름의 메소드가 여러개인 경우, 자식 클래스의 메소드만 사용된다.  class A{ void paint() { System.out.println("a") }}class B extends A{ void paint() { System.out.println("b") }}A a = new A();B b = new B();A a2 = new B();a.print() // a출력b.print() // b출력a2.print() // b출력 A클래스의 인스턴스 a가 paint()를 호출하면, a가 출력된다B클래스의 인스턴스 b가 오버라이딩된 paint()를 호출하면, b가 출력된다A클래스 타입을가진 B클래스 a2가 오버라이딩된 paint()를 호출하..

서비스를 개발하던 도중 테스트 코드를 작성해야할 필요가 있었고,  bcrypt와 같은 외부라이브러리를 사용할때, 함수 모킹이 되지않고, 테스트속도가 오래걸린다는 문제가 있었습니다 (bcrypt와 같은 암호화하는 작업들은 cpu 작업량을 많이요구하고 시간도 오래걸립니다)      문제가 생긴 메서드import * as bcrypt from 'bcryptjs';async signIn(loginDto: LoginDto): Promise { const channel = await this.prisma.channel.findFirst({ where: { id: loginDto.id }, }); if (!channel) { throw new UnauthorizedException(..

모듈 분리, 서비스 코드 분리 기준에 대해 생각해보자 각각 언제해야할까?    예를들어 댓글 CRUD기능과 댓글 좋아요기능이 있다고 가정해보자 그럼 1. 댓글 CRUD기능과 댓글 좋아요 기능의 서비스 코드를 분리해야할까? -> 특정 서비스내의 메서드들 중에서 어떤 것은 export를 해야하고 어떤 것은 export를 할 필요가 없다(해서는 안된다). 이때 각 메서드들은 별도의 클래스로 분리해야한다( 객체지향설계 SOLID 중 인터페이스 분리 원칙)   (인터페이스 분리 원칙 : 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다. -> 사용하지않는 불필요한 메서드 들은 가져오면 안된다. 꼭 필요한 메서드들만 주입 받아야한다 )      2. 댓글 CRUD기능과 댓글 좋아요 기능의..

의존성 주입을 쓰는이유   1. 클래스간 결합도를 낮출 수 있다 -> 결합도를 낮춘다는 것(의존성을 줄인다는 것)은 변화에 강하다는것 객체의 생성과 사용을 분리한다 다른 객체를 직접 생성하지않고 외부에서 필요한 객체를 주입받기 때문에 각 역할을 분리할 수 있다    2. 테스트가 가능하다* -> 테스트코드를 작성하는 것은 별도의 모의 객체를 생성하고 그 객체의 함수가 어떤 값을 반환한다고 가정한다(모킹)  -> 이것도 의존성을 낮춰줘서 가능한일. 의존성 주입을 하지않으면 모의 객체의 함수를 모킹하는것이 아니라 실제 클래스의 함수를 가져와야하는데, 그럼 문제가 발생한다. 실제로 동작하면 안되는 것들이 동작하게 될 수 있다. 실제객체가 아닌 모의객체를 이용한 테스트가 가능해진다  (예시1 : db연결이 실제..