Frontend

문제상황 Teengle 프로젝트는 웹뷰프로젝트로, 모바일 기기에서 실행되어야하다보니, 여러 정보를 작은 화면에서 조회하기위해서 상당히 많은... Carousel이 필요했다. Non-Indexed Carousel 첫번째 Carousel은 커뮤니티 피드에서 마치 스레드처럼 여러개의 사진을 볼 수 있는 기능에 필요했다. 이 Carousel은 아래 사진 처럼 스크롤한 만큼 자유롭게 이동이가능해야했다. 그냥 overflow scroll로 구성해서는 스크롤 속도가 너무 빨라서 사용할 수 없었다. Indexed Carousel 두번째 Carousel은 투표기능에서 여러 투표를 슬라이드를 통해 확인하기 위해 필요했다. 이 Carousel은 스크롤시에 요소를 중앙으로 배치시켜주어야 했기에 Non-Indexed와 로직은 ..

배경 새로운 프로젝트는 많은 사용자들이 모바일 환경에서 사용할 수 있도록 앱 형태를 택했다. 또, 플레이스토어/앱스토어에서의 업데이트 없이, 실험을 통해 앱을 지속적으로 빠르게 업데이트해보고자 그 중에서도 웹뷰를 선택하게 되었다. 사실 웹뷰는 토스/당근에서 다양한 실험/빠른 업데이트 때문에 사용한다는 이야기를 들은 뒤부터 사용자에게 정말 유효한 가치를 전달하려면 꼭 필요한 기술이라고 생각해서 꼭 한번 도전해보고 싶었다. 문제 웹뷰 화면 설계를 이야기 하지 않을 수가 없다. 웹뷰, 아니 앱의 문제점중 하나라고 한다면, 바로 스토어 리젝이다. https://orangebrother.dev/blog/app_why_reject iOS / Android 앱 심사 시에 발생하는 Reject 사유들 앱을 배포하기 위..

들어가며 프렌딩에서 프로필 교환 관련 개발을 하고있었다. 여기서 프로필 교환이란, 나와 상대의 프로필 카드를 교환하는 것이다. 마치 명함을 교환하는 것처럼 말이다. 그런데 여기서 약간의 문제가 생겼다. 앱인 경우에는 프로필 공유를 하게되면, 해당 프로필을 가진 사람의 기기에 푸시알림을 보내서 친구추가를 하는 형태였지만, 앱을 설치하지 않은 사람이 설치한 사람의 프로필 링크를 받거나, QR을 찍는 경우 어떻게 할지가 고민했다. 결론은 앱을 설치하지 않은 사용자의 경우 웹을 띄워서 어떤 프로필인지 볼 수 는 있게 해주자 였는데, 이걸 어떻게 안전하게 구현할 수 있을지가 고민이었다. 그냥 프로필 id로 보여주면 되는거 아님? 웹링크는 랜딩 사이트를 이미 개발했고, 배포해두었기때문에, 랜딩 사이트의 url을 사..

문제점 성능을 측정해보기 위해 lighthouse를 사용하던 중 점수대가 심상치 않다는 것을 알게되었다. 무려 79점...이었다. 문제파악하기 우리 AlgoITNi는 Home과 Room 두가지 페이지로 구성된다. 대부분의 기능은 Room에 필요하고, Room에서만 사용한다. 그러나, 리액트는 SPA이기에 이런 모듈들을 Home을 렌더링할때도 가져오게되고, 따라서 Home의 초기렌더링 성능이 나빠지는 것이라 추측했다. 확인해보기 프로덕션에서는 빌드가 완료된 청크가 네트워크 응답으로 오기때문에 정확하게 분석하기 어렵다. 따라서 개발환경에서 Home에 접속했을때 개발자도구의 네트워크 탭을 통해 어떤 코드를 불러오는지 확인했다. 빨간색 부분이 Room에서 필요한 코드들이다. 즉, Home에 접근했을때는 필요없는..

문제점 네이버 부스트캠프에서 진행하고 있는 AlgoITNi프로젝트에서 아래와 같은 문제가 발생했다. 빌드하는 과정에서 이러한 경고 메시지가 발생한 것이다. 특정 청크가 500KB보다 크다는 것이 문제이다. 위 사진을 보면 번들사이즈가 1285kb이고, 사용자가 실제로 받는 번들사이즈인 gzip사이즈가 425.33kb이라 초기 렌더링이 느려질 수 있다는 문제가 있다. 청크 사이즈 줄이기 청크 구조 분석하기 원인을 알기위해서 vite-bundle-visualizer를 사용해서 청크의 시각적인 분석을 해보았다. highlight.js가 번들의 절반을 차지하고있었다. highlight.js는 에디터에서 코드하이라이팅에 사용되는 라이브러리인데, 여러가지 언어를 모두 지원하기때문에 이렇게 라이브러리 사이즈가 커지는..

그럼 이걸 활용해서 yml을 만들어보자. Github Actions Github Actions는 github에서 제공하는 CICD 툴으로써, 코드 저장소에 어떤 이벤트가 발생했을때 특정 작업을 일어나게 하거나 주기적으로 작업을 반복 실행시키는 일을해준다. 이에 따라 브랜치마다 다른 일을 할 수 있도록 처리해줄 수 있다. 그럼 브랜치마다 어떻게 작동하게 만들지 전략을 수립해보자. 배포 브랜치 전략 수립하기 우리팀은 프론트엔드 코드와 백엔드 코드가 한 레포지토리에 있기때문에, 각 파트별 배포가 필요한 상황이었다. https://github.com/boostcampwm2023/web05-AlgoITNi GitHub - boostcampwm2023/web05-AlgoITNi: 동료와 함께 할 수 있는 플랫폼, ..

CICD를 구성하기전에 우선은 배포를 위한 서버 자원(S3, CloudFront, IAM)을 생성하고, AWS CLI를 사용해보자. S3만들기 클라우드 프론트를 통해 OAC설정을 할것이기에 ACL비활성화, 퍼블릭 엑세스 차단설정을 해도된다. CloudFront배포 만들기 원본 도메인으로 S3 버킷을 연결시켜주자. OAC설정하기 클라우드 프론트로만 S3에 접근할 수 있도록 S3의 정책을 변경해주자 S3에 파일을 업로드 하기 웹 콘솔에서 업로드 버튼 누르기 사실 업로드하는 방법은 간단하다. AWS 콘솔에서 업로드 버튼을 누르면 된다 허허 그런데 git에 push 할때마다, 직접 빌드하고 빌드한 파일을 업로드 하기에는... 우리는 너무 할일이 많고, 충분히 자동화시킬 수 있는 부분이다. 그래서 github a..

들어가며 네이버 부스트캠프의 그룹프로젝트 과정에서 진행했던 AlgoITNi의 배포전략, 선택한 이유, 방법들을 기록해두고자 한다. 프론트엔드에서 배포는 어떻게 이뤄지는가? 프론트엔드의 배포는 결국 html,css,js 정적파일을 서빙하면 끝이다. (SSR 제외) 좀더 세부적인 동작은 이전에 작성한 아래의 게시글을 참고해주면 좋을 것 같다. https://0422.tistory.com/312 프론트엔드 웹서버 직접 만들기 (1) - Content-Type, MIME 프론트엔드 개발을 해본 사람이라면 vscode의 live-server, webpack-dev-server, vite등등 다양한 도구를 사용해서 프론트엔드 서버를 띄워본 경험이 있을 것이다. 심지어 express를 사용한 서버에서도 static ..

https://0422.tistory.com/334 실시간 동시편집 구현 연대기 (3) - Yjs를 도입해보자 이전 게시글에서 문제가 있어서 Yjs를 도입하기로 했다. 이 글을 통해 어떻게 도입했는지 작성해보려고한다. Yjs알아보기 공유 타입 선택하기 Yjs는 다양한 타입을 지원한다. map도있고, array도 있 0422.tistory.com 이전 게시글에서 CRDT를 Yjs를 사용해서 구현했다. 하지만, 언젠가는(하겠지...?) 직접 구현해놓고 싶기때문에 라이브러리를 통해 만들어둔 기능을 언제든 내가 만든 모듈로 교체할 수 있도록 처리해둘 것이다. 문제점 실제 구현부인 handleRecieveCodeMessage, 즉 통신을 통해 다른 피어의 코드 데이터를 받았을때의 로직인데, 대부분이 Yjs의 모듈..

이전 게시글에서 문제가 있어서 Yjs를 도입하기로 했다. 이 글을 통해 어떻게 도입했는지 작성해보려고한다. Yjs알아보기 공유 타입 선택하기 Yjs는 다양한 타입을 지원한다. map도있고, array도 있다. 하지만, 우리는 코드 에디터니까 text를 선택했다. 이렇게 사용할 수 있다. insert를 통해 n번 인덱스에 문자를 삽입하는 형태다. toString을 통해 실제 텍스트를 얻어올 수 있다. delete역시 동일한데, insert와 다르게 length를 두번째 인자로 받는다. 어떻게 병합하지 여기서 핵심만 보자면 // Merge changes from remote const update = Y.encodeStateAsUpdate(ydocRemote) //update용 객체(Uint8Array다) ..