- 전체보기(13)
- yarn(6)
- nest(6)
- nextjs(5)
- next(5)
- Workspace(5)
- NestJS(5)
- Berry(5)
- react native(4)
- monorepo(4)
- next.js(3)
- typescript(3)
- aws(2)
- docker(2)
- React(2)
- Native(2)
- docker-image(2)
- v3(2)
- lambda(2)
- next13(1)
- ESOCKETTIMEDOUT(1)
- msa(1)
- 캐시(1)
- 캐싱(1)
- material(1)
- studio(1)
- 13(1)
- code(1)
- Visual(1)
- vscode(1)
- microservice(1)
- mui(1)
- Gateway(1)
- caching(1)
- esbuild(1)
- http(1)
- plugin(1)
- Cache(1)
- ts-node(1)
- nest.js(1)
- ESLint(1)
- Prettier(1)
- UI(1)
- tcp(1)
- app Directory(1)
MSA, Gateway 그리고 Nest
회사에서는 고객의 별도의 요구가 있지 않을 경우 API 서버는 MSA (Microservices Architecture 이하 MSA)로 구성합니다.서버는 대부분 한개의 테이블을 가지고, 하나의 테이블은 One Table Design Pattern으로 구성한 여러 모델의
Yarn Berry(v3) Workspace - 부록 VSCode Plugins
yarn workspac 연재를 진행하면서 많은 글을 구글링 하다 몇가지 관심가는 흥미로운 캡쳐 화면을 보게 되었습니다. 그러다 찾게된, monorepo환경에서 개발을 도와주는 Visual Studio Code 플러그인. packages 하위에 있는 패키지 루트를 vs
Yarn Berry(v3) space #4 - React Native 설정
목표로 하는 연제의 마지막 React Native를 yarn workspace 적용 입니다.React Native는 폴더 내부의 node_modules를 사용하도록 설정 해야 합니다
Yarn Berry(v3) Workspace #3 - Next.js 설정
Yarn Berry workspace를 사용해서, 프로젝트에서 활용하고 있는 프레임웍을 하나씩 설정하는 작업을 하고 있습니다. 이번 순서는 Next.js 입니다.
Yarn Berry(v3) Workspace #2 - Nest 설정
Yarn Berry workspace에 nest project를 포함하고, 라이브러리를 이용할 수 있도록 합니다.
Yarn Berry(v3) Workspace #1 - workspace 설정
Yarn Berry workspace의 설정에 대해 설명합니다. typescript, eslint / prettier, jest 등 실무에 필요한 설정을 한번에 모았습니다.
NestJS ESOCKETTIMEDOUT (ts-jest)
몇일 전부터 NestJS 프로젝트 생성을 하는데,,지속적으로 오류가 나고, 생성이 되지 않았습니다.내용을 추적 해보니 'ts-node' 설치 단계에서 계속 대기가 걸리는 것을 확인 했습니다.오류가 몇일이 되었는데도 git에 issue를 찾아봐도 별다른 report도 없
Next.js 13 app Directory와 MUI
Next.js 13의 새로운 기능인 'app Directory' 환경에서 Material UI (이하 MUI)를 적용하는 방법을 정리 합니다.
Yarn 3 MonoRepo with Typescript (Next.js, Nest, React Native)
MonoRepo란 Monolithic Repositories의 약자로 하나의 리포지토리에 여러개의 프로젝트가 구성된 형태를 의미 합니다.MonoRepo에는 장점과 단점이 있지만, 저에게는 하위폴더로 분리된 여러개의 프로젝트를 한번에 관리 및 코딩할 수 있는점과, 프로젝
Next.js + Lambda + Docker Image
Next.JS로 만든 웹 서비스를 배포하는 많은 방법 중, 초기 비용 부담이 없이 서비스를 시작하고,시스템 관리 없이, 증가하는 트래픽 처리를 할 수 있는 플랫폼을 테스트 하게 되었습니다.AWS Lambda가 우선 순위에 올랐고, 단점이던 용량 한계도 ...
NestJS Caching 응용
프로젝트를 진행하면서, 서버의 케시 적용은 오픈 일정에 맞추기 위한 우선 순위에서 밀려 항상 뒺전으로 밀리는 경우가 많았고, 적용하지 못하고 오픈하는 경우가 다반사 였습니다. 프로젝트 후반에 적용 하려면 테스트 중 변수도 많고, 잘 작동하지 않게되면 캐시적용 포기하고
Nest + Lambda + Docker Image
MSA(Microservices Architecture)로 백엔드 시스템을 구축할 때 Kubernetes를 이용하는것을 선호 하지만, 서비스 초기에 고정비용에 대한 고민을 하게 되었고,AWS의 lambda를 이용하여, 사용한 만큼만 비용을 지불 하는 방식을 검토하게 되