FE 개발일지

저번 글에서는 CI / CD 구축을 위한 기본적인 개념과 큰 틀에 대해서 설명했다면 이번 글에서는 git action과 aws에서 설정해줘야 하는 작업들에 대해서 설명을 해볼까 한다. CI / CD를 구축하면서 느낀점은 내가 해오던 프론트 개발과 정말 다른 세계라는 생각을 많이 했던 것 같다. 심지어 딥하게 들어간 것도 아니고 간단하게 맛만 본 것 같은데도 이런 느낌이 들어 새삼 인프라 구성을 하시는 DevOps 포지션이나 백엔드 분들에게 존경심이 느껴졌다. 그러면 이제 CI / CD 구축을 위한 Step을 밟아보자! 1. S3 버킷 만들기 버킷 이름을 설정해주고 AWS 리전을 설정한다. 여기서 객체 소유권 설정을 해주지 않아 "File upload failed : AccessControlListNotS..

이번에 새로운 프로젝트에 투입되면서 초기 단계에서 개발을 진행중이다. 아직 CI CD 구축이 되어 있지 않았는데 항상 백엔드 팀에서 해주셨는데 이번에는 내가 맡게 되었다. 같이 일하시던 백엔드 팀원분이 이직을 하게되었는데, 인수인계 및 잔여 업무들이 많은 것 같아 CI / CD 작업을 가져왔다. 해보고 싶었던 작업이기도 했고 여러모로 좋은 경험이 될 것 같아서 흔쾌히 진행하게 되었다. 현재 프로젝트는 리액트로 진행하고 있고 Git Action과 AWS를 이용해서 CI / CD를 구축할 계획으로 서치를 했다. 위 과정을 간략하게 설명해보자면 코드를 Push 하면 Git Action이 실행되어 CI (빌드) 작업을 수행 빌드 작업을 통해 zip 파일과 사전에 작성한 배포 스크립트 파일을 압축해 AWS S3에..

In-AppBrowser사용자를 별도의 웹 브라우저 앱으로 리다이렉트 하지 않고 앱 자체 내에서 웹 페이지를 열 수 있도록 해주는 기능앱 내에서 액세스 할 수 있는 기능이며, 일반적으로 장치의 기본 웹 브라우저를 기반으로 함사용자의 기본 웹 브라우저와 동일한 방식으로 동작하기 때문에 더 일관되고 친숙한 사용자 경험을 제공독립형 브라우저 앱과 동일한 기능을 모두 갖추고 있음#1 In-app-browser? 안녕하세요. 인앱 브라우저 환경 고려하기라는 주제로 포스트를 써볼까 합니다.인앱은 용어 그대로 앱안에서의 브라우저입니다. 앱 안에서 모든 활동이 이루어지죠. 저희는 이러한 환경을 고려하지 않고 서비스를 오픈했다가 큰 이슈를 겪은 경험으로 문제와 해결을 어떻게 했는지에 관한 포스트입니다.#2 문제저희는 서..

7월달에 어드민 개선하기 글을 쓰고나서 이제야 어드민 프로젝트 재구축을 완료하였습니다. 중간에 다른 업무와 병행하느라 예상했던 것보다 좀 더 걸렸네요. 많은 문제가 있던 어드민을 완료하고 이제 QA 진행에 들어갔습니다. 기존에 제기 되었던 문제(Recompiling 시간, 타입추론, 버그 양산 코드 제거, API 문제 등)들은 당연히 다 해결되었습니다. 항상 어드민 작업을 맡게 되면 그리 규모가 크지도 않은 프로젝트의 Recompiling 시간 때문에 한숨을 쉬었던 기억이 많았는데 되게 뿌듯하면서도 문제가 생기지 않을까 염려되기도 하네요. 오늘은 어드민 프로젝트를 다시 작업하면서 느꼈던 많은 부분들 중 제 스스로의 피드백과 함께 회고글을 작성해볼까 합니다. - 사용기술 React, React-router..

글을 쓰기에 앞서 어떤 문제가 있다고 해서 무조건적으로 프로젝트를 재구축하거나, 리팩터링을 거쳐서 개선하자는 위험할 수 있다고 생각합니다. 개발자 이외의 사람들이 보기에는 문제없이 잘 진행되어 있는 프로젝트일 수 있고 재구축을 진행하면서 어떤 변수가 일어날지 알 수 없기 때문에 정말 많이 고민하고 신중해야 할 것 같습니다. 1년 전 어드민의 대한 문제가 제기되어 다른 사람 주도하에 어드민이 재구축 되었고 현재 재구축된 프로젝트에 대해 다시 문제가 제기되고 있는 상황입니다. 주도 했던 분의 개발 방식이 저희(현재 프론트 동료분과 저)와 맞지 않았고, 더 이상 이 프로젝트에 관여를 하지 않기 때문에 앞으로 어드민을 개발해 나가야 하는 저희의 개선 의견을 대표님께서 받아들여주셨던 것 같습니다. 문제점 파악하기..

어떻게 보면 저번 FE에서 OOP의 대한 고민 포스트의 대한 연장선일 것 같네요! API를 클래스로 바꾸어 react-query를 같이 쓰면서 한번 더 깨닫게 된 내용이니까요. 다들 Arrow Function 많이 쓰시나요? function과 Arrow function의 차이점은 저도 직접 경험했다기보다는 어떤 차이점이 있지?라고 찾아보고 이론적으로 접한적이 더 많은 것 같습니다. 간단하게 function VS arrow function의 차이점을 짚고 넘어가봅시다. 일반 함수의 this - 함수를 호출할 때 어떻게 호출되었는지에 따라 this에 바인딩 할 객체가 동적으로 결정된다. 화살표 함수의 this - 함수를 선언할 때 this에 바인딩할 객체가 정적으로 결정되고, 상위 스코프의 this를 가리킨..

다들 프론트엔드에서의 OOP(객체지향 프로그래밍) 어떻게 생각하시나요? https://www.youtube.com/watch?v=1V6mQom0paI&ab_channel=%EA%B0%9C%EB%B0%9C%EB%B0%94%EB%8B%A5 관련해서 개발바닥 유튜브 영상도 정말 재밌게 봤던 것 같습니다. 클래스에 대한 고민은 제가 타입스크립트를 도입하면서 같은 Url Prefix를 사용하는 Api들을 어떻게 묶어볼 수 없을까?부터 시작되었는데요. 레퍼런스가 많이 없기도 하고 실제로 FE에서는 FP가 더 중심적이고 OOP에 대해서 많은 고민과 고찰이 없었던 것도 사실인 것 같습니다. 굳이 필요한가?란 생각도 있구요. 그래서 더더욱 클래스를 도출하기까지 시간이 좀 걸린 것 같기도 합니다. 당연히 클래스만 쓴다고 ..

1. 확장자명 js, ts, tsx 파일 파일 확장자명 js에서는 뭐가 js고 jsx인지 모릅니다. 그러나 ts 파일 내에서는 ts와 리액트 컴포넌트들을 구분해서 처리를 하기 때문에 react에 관련 import 즉 tsx를 알 수 없습니다. 정리해보면 .ts - 순수 Typescript 파일에 사용 .tsx - JSX를 포함하는 파일에 사용 (리액트 구성요소) 간혹 모든 파일 확장자명이 tsx로 되어있는 것을 보면 아 이래서 그랬구나라고 깨달았던 것 같습니다. 저희는 로직만 담은건 ts로 처리하고 React 구성요소가 포함되어 있으면 tsx로 처리하기로 했습니다. 2. Typescript의 타입 자동추론은 정말 강력하다. 타입스크립트와 vscode 둘 다 마이크로소프트에서 만들었기 때문에 에디터간의 자..

TS 마이그레이션 이전에..이전에 디자인 패턴의 대한 고민과 redux-saga에서 react-query로 리팩터링을 진행했었는데요. 이 모든 리팩터링 과정은 타입스크립트 마이그레이션 전에 적용되어야 할 우선순위였습니다. 최종적으로 목표는 타입스크립트 마이그레이션이였고, 원할한 TS 마이그레이션을 위해 디자인 패턴을 바꾸어 필요없는 파일은 줄이 redux-saga로 관리되던 비동기 코드들은 react-query로 전환하여 원하는 기능들을 더 편리하게 사용하게끔 만들었습니다. 이렇게 타입스크립트를 위한 빌드업은 끝났고, 타입스크립트 마이그레이션을 하게 되었는데 결코 쉽지 않았습니다. 백엔드분들이 IDC에서 NCP로 이전을 해야되는 상황이였기 때문에 api작업은 원할하게 진행될 수 없던 상황이였고 프론트엔드..

저는 가장 관심있어 하는 부분 중 하나가 프로젝트를 밑바닥부터 쌓아 올릴 때, 이 프로젝트를 어떻게 빌드업 해나갈 것인가? 즉, 설계에 대한 부분에 큰 관심이 있습니다. 클라이언트단에 어떠한 요구사항이 들어와도 처리할 수 있는 능력과 프로젝트 설계 능력을 가장 중점적으로 생각하고 있습니다. 제가 처음 입사해서, 프로젝트를 맞이했을 때와 현재 시점에서 프로젝트를 볼 때 관점의 차이가 생기는 것 같습니다. 다들 프로젝트의 디자인패턴은 어떤 걸 사용하시나요? 처음 프로젝트를 맞이했을 때, 저희 프로젝트는 가장 기본적인 디자인 패턴 Container, Presenter패턴을 사용하고 있었습니다. Container에서는 비즈니스 로직과 관련된 코드, Api를 수행하고 state를 조작해서 props로 Presen..