개발자 커뮤니티와 Electron 앱 개발 경험 공유
개발자가 겪는 좌절과 성장의 과정을 개인적인 경험을 통해 묘사하며, 커뮤니티의 중요성을 강조함
Dev.to 데스크톱 클라이언트(Always with Dev.to) 개발 경험을 공유하며, Electron, Express, Supabase 등 기술 스택 소개
Electron 앱 내 Express 서버 임베딩, 단일 실행 파일 패키징, 캐싱, API 호출 재시도 등 구현상의 기술적 난제와 해결책 제시
Supabase를 활용한 사용자 인증 구현, API 응답 형태 변경으로 인한 문제 등 실제 개발 과정에서 겪은 문제점을 상세히 설명
개발자 커뮤니티의 중요성을 강조하며, 포용적인 개발 환경 조성의 필요성을 역설
Electron 앱 내 Express 서버 임베딩
저자는 Electron 앱 내에서 별도의 백엔드 프로세스 없이 Express 서버를 실행하는 방법을 제시한다.
임베디드 서버(Embedded Server) 방식: Electron 메인 프로세스 내에서 Express 서버를 실행하여 IPC(Inter-Process Communication) 및 포트 관리(Port Management) 오버헤드 제거
환경 변수 관리: 개발 환경과 패키징된 환경 간의 환경 변수 경로(Environment Variable Path) 자동 전환
기술적 이점: 단일 실행 파일(Single Executable File) 패키징을 통해 배포 및 관리가 용이하며, 백엔드 리소스를 함께 묶어 관리
이러한 방식은 Electron 앱의 성능을 향상시키고, 개발 및 배포 과정을 단순화하는 데 기여한다.
단일 실행 파일 패키징 기술
저자는 Electron 앱과 Express 백엔드를 하나의 실행 파일로 패키징하는 과정을 설명한다.
electron-builder 활용: `extraResources` 설정을 통해 백엔드 폴더(node_modules 포함)를 앱의 리소스 디렉토리에 복사
build 설정: `win` 설정을 통해 윈도우(Windows) 환경에서 portable 실행 파일(Portable Executable) 생성
심볼릭 링크(Symbolic Link) 문제 해결: `winCodeSign` 아카이브 내 macOS 심볼릭 링크로 인한 빌드 오류를 해결하기 위해 `binDownload.js` 패치
이러한 과정을 통해 사용자는 별도의 설치 과정 없이 앱을 실행할 수 있으며, 배포 및 업데이트가 용이해진다.
Dev.to API 호출 최적화
저자는 Dev.to API 호출 빈도를 줄이기 위해 캐싱(Caching) 기술을 적용했다.
LRU 캐시(LRU Cache) 구현: 최근 사용되지 않은 항목을 제거(Eviction)하는 LRU(Least Recently Used) 알고리즘을 사용하여 메모리 사용량 관리
TTL(Time To Live) 설정: 각 캐시 항목에 만료 시간(Expiration Time)을 설정하여 자동으로 캐시 무효화(Cache Invalidation)
패턴 기반 무효화(Pattern-based Invalidation): 특정 패턴에 해당하는 캐시 항목을 일괄적으로 삭제하여 데이터 변경 시 캐시 일관성(Cache Consistency) 유지
이러한 캐싱 전략은 API 호출 횟수를 줄여 성능을 향상시키고, API rate limit 문제를 해결하는 데 기여한다.
Supabase를 활용한 사용자 인증
저자는 Supabase를 사용하여 사용자 인증 기능을 구현했다.
Supabase 클라이언트 초기화: 환경 변수(Environment Variables)를 사용하여 Supabase 클라이언트(Client)를 초기화하고, 인증되지 않은 경우에도 앱이 동작하도록 Graceful Degradation 구현
JWT(JSON Web Token) 기반 인증: bcryptjs를 사용하여 안전한 비밀번호 해싱(Password Hashing) 및 비교, 토큰 기반 인증(Token-based Authentication) 구현
인증 흐름: 이메일과 비밀번호를 사용하여 로그인하고, 성공 시 JWT를 발급하여 Stateless 인증(Stateless Authentication) 구현
이러한 방식으로 안전하고 효율적인 사용자 인증 시스템을 구축했다.
API 응답 형태 변경으로 인한 문제
저자는 백엔드 리팩토링 과정에서 API 응답 형태를 변경하면서 발생한 문제점을 설명한다.
응답 형태 변경: 기존의 `data.filter()`와 같은 프론트엔드 코드에서 예상치 못한 오류 발생
문제 원인: 백엔드에서 응답을 `{ success: true, data: [...] }` 형태로 감싸면서, 프론트엔드에서 `data`를 배열로 인식하지 못함
해결 방법: 백엔드에서 raw data를 반환하도록 수정하여 기존 API 계약(API Contract) 유지
이러한 경험을 통해 API 변경 시 기존 클라이언트와의 호환성을 유지하는 것이 중요함을 강조한다.
