분류 전체보기 (96) 썸네일형 리스트형 Spring Boot와 비교해보는 Nest.js의 핵심 Nest.js의 공식 문서의 초입부에는 Controller... 까지는 알고, 실제로 이는 Spring과 정말 흡사하다.그렇지만 그것 이외에는 이름이 비슷하더라도 Spring Boot와는 많이 달랐다. Nest.js의 요소를 설명하면서 Spring Boot의 어떤 것과 대응이 되는지 파악해보자. 1. 의존성 관리 기본적으로 둘 다 주로 사용하는 객체를 싱글턴으로 구현하고, 의존성 주입을 프레임워크가 직접해준다는 점에서 공통점이 있다.더보기이를 IoC(Inversion of Control) : 제어의 역전 - 개발자가 프로그램의 흐름을 제어하는게 아니라, 컨테이너 혹은 프레임워크가 흐름을 제어한다. 예를 들어서 Spring의 Spring Container를 IoC Container라 하는데, 이는 Bean.. Nest.js과 TypeORM TypeORM에서 Entity의 사용은 JPA와 흡사해 보여서 쓰면서 적응하면 될 것 같기는 하다. https://docs.nestjs.com/recipes/sql-typeorm Documentation | NestJS - A progressive Node.js frameworkNest is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with TypeScript and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (.. Spring 개발자의 Nest.js 초입 작년에 개발에 입문 후 백엔드 개발에서 나의 학습의 진행은 아래의 순서와 같았다. 1. 사용할 언어에 익숙해지고; Java2. 그런 다음 웹 서버 프레임워크; Spring3. 마지막으로 고도화된 프레임워크를 다룬다; Spring Boot 같은 방식으로 이번에는 TypeScript와 express.js, Nest.js를 공부하려고 했으나일단 Nest.js를 배우기로 했다. express.js와 TypeScript는 Nest.js를 배워가면서 필요한 부분을 그때마다 찾아가는 식으로 해야 할 것 같다.무엇보다 Nest.js가 Spring과 그 구조가 유사하다고 말하기에, Nest.js를 배워가면서내가 모르는 문법이나 express.js(혹은 기타 JS기반 API 관련 내용)은 필요할때마다 알아가는 방식으로 진.. Terraform 핵심 프로세스 지난번 글https://namucy.tistory.com/93 Terraform을 통한 Infrastructure Provisioning서비스를 제공할 Infrastructure를 구성, 구축하는 것을 Infrastructure Provisioning이라고 한다. 연차가 많이 쌓인 개발자들은 코웃음을 칠 수준이겠지만, 본격적으로 개발이라는 것에 손대기 시작한 8월namucy.tistory.com Terraform을 IaC(Infrastructure as Code)라고 설명했듯이,Terraform은 코드, 프로그래밍 언어를 통해서 인프라를 구축하기 때문에 문법이 존재한다.Go 기반 HCL 선언형 언어로 관리되기 때문에 생소할 수는 있으나, 써본 경험에 의하면 JSON같은 느낌이다. 문법에 대한 설명은 .. Terraform을 통한 Infrastructure Provisioning 서비스를 제공할 Infrastructure를 구성, 구축하는 것을 Infrastructure Provisioning이라고 한다. 연차가 많이 쌓인 개발자들은 코웃음을 칠 수준이겠지만, 본격적으로 개발이라는 것에 손대기 시작한 8월부터이에 대해 관심을 가져왔고, 본격적으로 인프라의 구성과 배포를 배우기 시작한 10월부터는 배포 환경을 끊임없이 만들어왔다. 처음에는 AWS EC2 단일 인스턴스 하나 + Docker 사용을 통한 것이 전부였다.아직도 사용하는 것은 AWS뿐 이지만 그 안에서도 차근 차근 내가 다루지 못했던 인스턴스들, 서비스를 사용하며 영역을 넓혀가고 있었다. 하면 할 수록 느끼는 것은 인프라를 구축하는 데는 시간이 꽤 걸리고, 손이 많이 간다는 것이다. 도중에 어떤 값을 사용했는지도 일일이.. Refresh Token 회전(갱신) 시 발생하는 동시성 문제 문제 상황) access token이 만료되었을 때 frontend 쪽에서는 refresh token을 날리도록 하였다.만약, 한 페이지에 두 개의 api요청을 날린다고 한다고 가정하자.그리고 이 때 access token이 만료되었다면 어떤 일이 일어날까? 먼저 be는 두 개의 요청에 대해서 401을 날릴 것이다.그러면 자연스럽게 fe에서도 두 개의 요청에 대한 refresh token 요청을 날릴 것이다.즉 두 번의 refresh 요청이 들어온다. 문제는 이 때 발생한다.두 개의 refresh요청은 모두 같은 쿠키(같은 refresh token)를 통해서 들어온다. 첫 번째 요청이 들어올 경우, DB에 refresh token이 있는지를 확인 -> 있을 경우 refresh 토큰을 갱신하고, 기존의 것.. github action gradle cache 사용으로 빌드 시간 단축 (초안) gradle 매번 다운로드 후 설치했는데캐시 사용함.리포지토리당 5기가 제한깃허브 푸시 기본 시간 2000분이라고 하더라. + 예상되는 문제점 : 원래는 버전이 다를 경우 다른 gradle 사용할 가능성 있다.버전에 대한 값을 넣은 해시값 만들어서 관리하기에 문제는 없음.문제 상황 : gradle wrapper를 통한 JAR 빌드 과정에서 소요되는 시간이 매우 길었습니다.원인 파악 :Intellij에서 실험해본 결과, gradle 다운로드 및 설치하는 과정이 없었고, 빌드만으로 5초가 걸리는 반면,(물론 성능이 다른 것도 감안해야 할 것 같습니다.)github action상에서는 매번 새로운 가상 환경을 사용하기에,위의 로그처럼 다운로드 후 설치하는 방식을 사용하므로 시간이 오래 걸립니다.해결 방안 :어.. Thread와 자원 분배 문제 1. Thread의 정의와 만들어진 배경 스레드(Thread)란, 프로세스(Process) 보다 작은 프로그램의 실행 단위이다. 컴퓨터가 발달하면서 하나의 프로그램에서 복잡한 동시 작업의 필요성이 제기됐다.이에 따라서 하나의 프로그램에 여러 개의 프로세스가 필요했지만, 프로세스 간에는 자원의 공유가 어려웠다. 왜냐하면 서로 다른 프로세스는 완벽히 독립적인 메모리가 할당되기 때문이다. CPU가 프로세스의 작업 중에 다른 프로세스에게 작업을 전환하는 과정을 컨텍스트 스위칭(Context Switching)이라고 한다. 그런데 프로세스라는 단위 자체가 Context Switching에는 적합하지 않은 실행 단위이다. 각각의 프로세스는 고유한 스택과 데이터 영역을 가지고 이는 침범하지 않도록 보호받기 때문이다... 이전 1 2 3 4 ··· 12 다음
