끄적끄적 개발정리

이제 실제 구현에 대해 설명하겠습니다. 개발 구현은 구성은 아래과 같습니다. 대략적으로 설명하고 자세히는 설명하지 않겠다. ( 빌드 설정 역시 최소화하였다. 상황에따라 별도 설정이 추가로 필요하다. 실제로 적용하다보면서 추가로 설정해야할 부분이 많다. svg 설정이나 정적파일 처리 등등 ... ) Vite: 번들러 ( ESM 기반 dev server를 제공해줘서 개발자 경험이 매우 좋음. vitest 같은 테스트 러너를 같이 사용하기에도 매우 편하다) Vue: 프론트엔드 프레임워크 Storybook: 문서화 및 개발, 테스트 환경 제공 Chromatic: 스토리북을 빌드하고 변경 부분을 확인할 수 있는 기능을 제공해준다. ( Storybook, Chromatic 까지 다루기에는 너무 내용이 많아져서 생략..

최근 1년간 회사에서 디자인 시스템관련 작업을한 경험을 공유하려고 합니다. 완벽한 디자인 시스템을 만들었다고 생각하지 않지만 편의상 디자인 시스템이라고 하겠습니다. 최근 1년 작업하면서 느낀건 개발자들와 UX디자이너들이 생각하는 디자인 시스템이 많이 다르다는걸 느꼈습니다. 우선 디자인 시스템에 대해 설명하고 넘어가겠습니다. 개발자가 생각하는 디자인 시스템: Storybook + UI Component 로 구성된 구성 UX디자이너가 생각하는 디자인 시스템: Pigma or Zeplin 으로 구성된 컴포넌트 구성 + 폰트, 디자인 심볼 + 무언가를 통한 일괄적용 ( 앱 + 웹 ) 어떻게 보면 UX디자이너가 생각하는 부분이 완전한 디자인 시스템에 더 가깝습니다. (적용은 다른 얘기지만요...) 디자인 시스템을..

필요성 웹상에서 적절한 font를 보여주는 것은 매우 중요하며 웹폰트를 사용하지 않고 내장폰트를 이용한다면 내장폰트에 맞게 적절한 폰트수치를 사용하는게 중요하다. 현재 운영중인 iOS, Android에서 제공되는 웹뷰에서 각기 다른 폰트가 적용되고 있다. (별도의 웹폰트를 사용하고 있지 않다.) iOS, Android 모두 디바이스에 내장된 폰트를 사용하고 있습니다. iOS의 경우 .AppleSystemUIFont, Android의 경우 Noto Sans CJK KR가 적용된다. iOS디자인 가이드상으로는 font-weigh을 600으로 사용하여야 하고 Android는 유사한 두께로 보여주기위해 700을 사용하여야 했다. 두 폰트의에 동일한 font-weight을 적용할 경우 한 쪽 폰트가 너무 두껍게..

Motivation Vue를 통해서 현재 두 가지 서비스의 프론트엔드 개발을 하고 있습니다. 추가적으로 신사업도 개발하게 될 것 같고 N개의 서비를 운영하게되겠죠 이렇게 개발해야하는 상황에서 공통기능 (컴포넌트, 유틸, 상수값 등)에 대해 어떻게 유지해야할지 고민하게 되었습니다. 1. 패키지 저장소를 구성하고 하여 관리하는방식 2. 하나의 저장소를 모노레포 구조로 구현하여 공통소스를 공유하는 방식 versioning을 해야하는 상황이고 관리할만한 인력과 환경이라면 1번 케이스가 베스트라고 생각했습니다. 하지만 고민해본 결과 당장 versioning을 해야하는 상황도 아니고 버전별로 관리하고 운영하게 더 어렵다는 생각이 들어서 MonoRepo 구조로 개발하기로 하였습니다. 구성 과정 모노레포 구조로 개발하..

드디어 3, 4 개월만에 톰캣으로 서비스하던 프론트엔드 서비스 대부분을 Amplify로 전환했습니다. 그동안 테스트를 작성하면서 많은 고민을 했습니다... 제스트 기반으로 공통모듈을 테스트하고 있지만 배포과정에서 전체 테스트를 돌리는건 비효율적이라고 생각이 들어서 주요 기능에 대해서 E2E테스트를 작성해서 Amplify 배포 과정에서 테스트 되도록 하면 좋겠다는 생각이 들었습니다. 제가 운영하는 서비스에서 예약, 취소 관련 기능이 중요하여 E2E테스트를 작성하고 배포하기로 하였습니다 :) 우선 기존에 작성했던 예약관련 E2E테스트를 수정해서 배포하였고 나머지는 시간날때 마다 조금씩 추가 하려고 합니다. 테스트작성 보다는 세팅하는 부분이 까다로워서 세팅 부분을 공유 해보겠습니다~ 우선 배포가 완료되면 아래..

배경 저는 웹페이지도 개발하고 있지만 앱내에서 보여지는 주문, 예약관련 페이지도 개발하고 있습니다. 개발하고 있는 서비스는 Java 백엔드 기반으로 서비스 되고 있고 프론트엔드 배포를 위해서 백엔드도 같이 배포해야하는 문제가 있어 개선이 필요했습니다. 아무래도 프론트 개발은 수정요건이 자주 발생하고 이벤트성 개발도 있기때문에 개발, 배포과정이 비교적 짧은 경우가 많았습니다. 그런데 백엔드와 같이 배포하다보니 배포시간도 오래 걸리고 소스 관리 측면에서도 단점이 많았습니다. 그리고 백엔드 + 프론트서비스 2개로 구성되어 있는 모노레포 구조에서 프론트 서비스를 동시에 2개 서비스 하고 있기때문에 프론트 공통 모듈등을 잘못수정하여 배포한다거나 실수로 수정대상이 아닌 서비스를 잘못 수정하여 배포한다면 서비스에 장..

뷰 리액트에 대한 비교글은 많지만 제가 실무에서 사용하면서 느낀점에 대해서 주관적으로 포스팅해보려고 합니다. 주관적인 관점에서 포스팅 하는만큼 잘못된 점이나 다른 의견은 댓글로 알려주시면 감사하겠습니다. Vue 3.x 버전에 대해서 다루겠습니다. ( MS가 IE 지원을 드랍한 상황에서 Vue 2.x 를 더 이상 사용할 이유가 크게 없기 때문입니다. ) Vue 3.x 버전부터는 React와 상당히 유사합니다. 간단히 카운트를 증가시키는 기능을 예제로 보겠습니다. React import { useState } from "react"; import "./App.css"; function App() { const [count, setCount] = useState(0); const addCount = () =>..

네트워크 환경이 충분히 좋고 디바이스 성능이 뛰어나다면 별도의 최적화 작업등이 무의미 할 수 있다. 이런 최적화 작업은 좋지못한 환경에서 빛을 바란다. 전제조건 1. Optimized 이미지를 사용 2. 네트워크 환경이 좋지 못함 3. Low Performance Device를 사용중 이미지 포멧등의 최적화는 적용하기 나름이기 때문에 최적화 되었다는 가정하에 진행한다. 핀터레스트 같은 사이트를 보자 https://www.pinterest.co.kr/ 빨간색 영역이 디바이스에 보여지는 영역(View port)이고 파랜색 영역이 랜더링되는 영역이다. 실제 파란색영역은 세로로 더 긴영역을 차지한다. 이럴경우 실제 최초 로딩에 필요한 부분은 화면에 보여지는 영역뿐이다. 이때 사용할 수 있는게 Intersecti..

최근 로딩성능 개선을위해 https://developers.google.com/speed/pagespeed/insights/?hl=ko 을 통해 개발중인 서비스의 개선점을 자주 모니터링하고있습니다. 개선 과정중에 http => https 로 리다이렉트 시키는 js파일이 랜더링 차단요소에 나타난걸 보고 제거하기로 했습니다:) AWS Elastic Beanstalk를 사용중이고 적용할 수 있는 방법이 있나 찾아보니 로드벨런서를 이용한 리다이렉션이 가능했다. 현재 사용하고있는 로드밸런서는 Classic Load Balancer였고 Redirection을 지원하지않아 Application Load Balancer로 변경하기로 하였다. 지원 가능등은 아래 링크를 통해 비교가능하다. https://aws.amazo..

필요성 이번에 부족한 개발인원으로 인해 외주업체에 프론트엔드 개발을 주면서 자동 배포환경이 필요하게 되었다 기존에는 aws cli를 통해 배포 하고있었으나 그러기 위해선 pem파일을 공유해야 하고 일부 AWS권한을 부여해야하는 문제가 있었다. 그러나 외주업체에 AWS접근권한을 준다는것에 대한 거부감이있었고 github actions를 통해서 자동배포환경을 구성하게 되었다. 찾아보면 Github Actions 템플릿이 많이 존재하여 생각보다 쉽게 구성할 수 있다. 프론트엔드 배포를 위해 아래와 같은 조건을 충족하여야 했다. 1. github push 많으로 빌드, 배포가 자동적으로 이루어져야한다. 2. package.json 기준으로 패키지 인스톨이 가능해야한다. 3. 빌드 과정을통해 production에..