1년차

서비스를 배포하기 위해 docker를 실행해야하는데 나의 PC에서는 실행이 안되고 다음과 같은 에러를 보였다.읽어보면 WSL update가 failed 했다고 나온다. 일단 WSL이 뭔지 알아야했다.WSL: Windows Subsystem for Linux Window

운영서버에 배포를 진행하였다.로컬 환경에서는 잘 적용이 되었는데 배포 후에 이전 버전을 보여주는 일이 있었다.이유: 동일한 url 요청을 한다면 웹 브라우저는 js, css(기타 정적 파일들)을 스스로 캐싱하여 브라우저 최적화한다.해결방법은 간단하다. 개발한 페이지가

Mater -> 운영/배포용 브랜치Develop -> 여러 기능이 합쳐지는 브랜치feature/ -> 새로운 기능 (Local에서 개발) 브랜치각각 Mater는 시스템 테스트, Develop은 통합 테스트, feature은 단위 테스트가 이루어진다.Github만 사용

우리 서비스는 총 3개(1개는 출시 예정)가 있다. 모두 이커머스 서비스로 Admin 페이지의 구조가 동일하다. 디테일한 부분은 각각 다른 점이 있지만 파일을 나누어 관리하는 것보다 하나의 파일에서 관리하는 것이 좋지 않겠냐고 CTO님께서 제안을 하셨다. 그래서 Adm

C 서비스의 개발서버 배포를 하면서 S3로 배포되는 과정을 알게되었다.EC2로만 배포를 진행했었는데 S3 버킷을 사용하여 배포가 가능하다. 단, 정적 페이지만 배포가 가능하다.그 과정과 사용 이유를 알아보자.package.json 파일을 보면 다음과 같은 명령어가 있었

우리 서비스는 Admin은 ReactTS(CRA), S3, Cloudfront, Route53 으로 개발/배포가 진행된다. 실제 서비스는 NextTS, EC2, S3, Docker로 개발/개포가 진행된다.처음엔 이렇게 생각했다.나의 가설로는 CloudFront에서 이전

우리 서비스의 폴더구조를 살펴보니 Page Router로 되어있다.그런데 내가 이전에 배웠던 AppRouter와 달라 그 차이를 알아보았다.먼저 AppRouter는 Next 13버전에 나온 라우팅 방법이다.라우팅 뿐 아니라 렌더링 방식 또한 다르다.App Router는

프론트엔드 배포 업무를 맡으면서 다양한 환경에서의 배포를 경험하고있다.각 서비스의 특성에 따라 다르게 배포가 진행된다. 웹 서비스 (NextTS) -> ec2, nginx, docker웹 어드민 (React) -> s3, routes53, cloudfront웹 뷰(Ne

우리 서비스 중 웹 뷰(Next.js)는 EC2 nginx pm2 로 서버를 구축했다.사실 필자가 위 내용을 이해하지 못했던 이유는 경험 부족 때문이다.React 로 개발 후 Vercel 배포 경험사실 Vercel이나 Netlify 와 같은 SaaS(Software a

이미지 출처우리 서비스는 docker를 활용해 local - ecr(docker push) - ec2 (docker pull) - nginx container 실행 및 서비스 blue/green 배포 웹 서비스 요청 시 ec2에서 돌아가고 있는 nginx contain

우리 서비스는 이커머스 서비스이다.그렇다보니 가끔 특가 이벤트를 한다. 이번 특가 이벤트는 갑작스럽게 시작되어..미리 대비를 하지 못한 이슈가 있었다..! 백엔드 개발자분께서 API요청이 단기간에 몇 십만 건 들어왔다고 말씀해주셨다 ㄷㄷ그래프를 보면 서버가 안죽은게 신

감사히 단독으로 라이브 스트리밍 클라이언트단을 개발해볼 기회를 얻었다..! 사실 이 글을 쓰는 시점은 이미 라이브 스트리밍의 일부 데모 개발을 마친 시점이다.중간점검 느낌으로 그 간 개발 과정을 정리해보자 ! 팀장님께서 위 두 가지 서비스를 통해 우리 라이브 스트리밍

우리는 Low-Latency Streaming 을 선택했고 그 중 Timed MetaData를 눈 여겨 보았다.이처럼 segment를 보내는 과정에 metadata를 주입하여 broadcast 하는 송출자와player를 통해 방송을 보는 수신자가 동일한 타이밍에 데이터

AWS IVS의 장점이라고 생각되는 부분은 Player, Chat, Broadcast가 각각 독립적이라는 점이다.우리는 AWS IVS가 제공하는 SDK를 보면 다음과 같다.크게 3가지 SDK 를 제공하는데 Player, Chat, Broadcast 이다. 사용해보면 각

이번 역시 공식 홈페이지를 기준으로 설명해보자먼저 Player sdk는 npm을 통해 설치하지 않고 script 태그를 head에 넣어주었다.가져온 sdk를 통해 player를 생성하고 시작할 수 있다.그런데 만약 해당 스트리밍이 비공개 즉, 재생 권한 부여에비디오 재

라이브 스트리밍을 개발하면서 고민했던 부분 중 하나는 "방송상태체크"이다.크게 2가지 체크사항이 있었다. 1\. 방송중인가?2\. 그렇다면 방송 상태는 어떤가? (네트워크 불안정, 지연율 체크 등)방송중 체크를 할 수 있는 방법은 다양하다.aws-sdk@clients

Ivs Player 로직을 짜면서 헷갈렸던 코드 흐름이 있다.Chat 부분인데 코드를 보면최상위 컴포넌트이고 Chat 컴포넌트는이고 내부 useConnectChat와 useGetManageFn은 각각나의 생각으로 일단 manageFn이 undefined 될 수도 있을

우리 서비스는 3개의 플랫폼에 각각 어드민이 존재하는 형태이고그 중 하나의 플랫폼에서 라이브 스트리밍을 시범할 예정이다.해당 플랫폼의 서비스, 어드민, 웹뷰 가 존재하는데 라이브 스트리밍을 개발하다보면 공통 코드들이 존재한다. 방송 연결/제어, 채팅 연결/제어, 방송

기존 라이브러리는 번들러를 사용하지 않았다.tsc를 사용하여 컴파일만 적용했고만약 코드 용량이 많아졌을 때 효율이 좋지 않을 수 있다고 생각했다.참고 블로그타입스크립트의 컴파일러는 TS → JS 트랜스 파일링만을 지원트리쉐이킹, Minify등을 제대로 지원하지 않는다.

문제 상황 >private npm registry를 사용한 라이브러리 (@firstenter/cuma-ivs)를 사용하면서 배포 시 해당 라이브러리를 빌드하지 못하는 오류가 발생함 해결 방법 >.npmrc 파일을 사용하여 npm config 파일을 주입하여 bui

React 기반 프로젝트를 개발하다보면 리렌더링이 일어났을 때 필요한 코드만 딱! 실행되게 하는게 중요하다고 많이 느낀다. 리렌더링에 따른 함수의 실행이나 렌더링을 제어할 수 있는 방법은 다양하다.오늘은 그 방법들을 정리하고 내 나름 분석을 해보겠다.자, 먼저 리렌더링

우리 서비스의 라이브 스트리밍 기능은 라이브 화면 위에서 결제가 모달 방식으로결제 수단 선택 -> 결제 검증 -> 결제 완료 과정이 거쳐져야한다.즉, 사용자의 UX를 고려했을 때 Player 위에서 결제가 하나의 흐름으로 진행되어야한다.기존 결제 방식은 토스페이먼츠 위

서른오늘 포스팅은 Timed metadata를 처리하면서 발생했던 트러블 이슈를 다루어보겠다.우리 서비스는 aws ivs의 chat / player / broadcast sdk를 모두 사용한다.이때, Player는 송출자가 Player에게 단방향으로 메타데이터 (jso

프로그램이 실행된다 ? 정적 테스트 : 동적테스트정적 테스트: 프로그램을 실행하지 않고 명세서나 소스 코드를 분석하는 테스트ex) 워크스루, 인스펙션, 코드 검사특징 개발 초기에 실행소프트웨어 개발 비용을 낮출 수 있다.쉽게 말해 작성된 코드를 팀원들 앞에서 소개 (실

출처 - 애니메이션 나루토 속 바꿔치기 술법테스트 코드를 본격적으로 작성하며 알아야할 게 많이 있는데 그 중 먼저 기초가 되는 jest의 mocking에 대해 알아보자mock 이란 모조품 즉, 가짜이다.진짜를 가짜로 바꿔치기 후 테스트 수행할 때 필요한 기술왜 mock

headless browser