본문 바로가기

Client/Front-end

(13)

<FE> Frontend-DevOps: 모던 프론트엔드의 역할 1. 소개 DevOps 라는 분야를 들어본적이 있을 것이다. DevOps는 개발(Dev)과 운영(Ops)의 결합을 통해 소프트웨어 개발 생명주기 전반에 걸쳐 효율성과 품질을 향상시키는 방법론과 도구 집합을 의미한다. 이는 지속적인 통합(Continuous Integration), 지속적인 배포(Continuous Deployment), 자동화된 테스트, 인프라스트럭처 코드화(Infrastructure as Code), 모니터링 및 로깅 등 다양한 관행과 도구를 포함한다. 이러한 방법론이 최근 Front-end 개발자에게도 요구되기 시작했다. 현대의 웹과 애플리케이션 개발 환경은 빠른 기술 변화와 다양한 요구 사항이 빠르게 변화하는 특성을 가지고 있다. 이러한 환경에서 프론트엔드 개발자들은 사용자 인터페이..

<BFF> BFF 개발 시의 고려요소 1. 소개 - 지난 포스팅에서는 BFF란 무엇인지, 어떻게 구현될 수 있는지 알아보았다. BFF는 프론트엔드와 백엔드 사이에서 중간 계층으로 동작하는 서버이다. 서버이기 때문에 BFF를 개발할 때는 데이터 통신, 보안, 성능 최적화, 배포 등을 고려해야 한다. 이 포스팅에서는 BFF 개발 시 이 네 가지 요소에 대해 자세히 알아보고, 각 요소의 중요성과 고려사항을 살펴보겠다. 2. 고려사항 * 데이터 통신 - BFF의 데이터 통신은 프론트엔드와 백엔드 간의 효율적인 데이터 전송을 위해 중요한 요소다. 데이터 통신을 최적화하기 위해 다음과 같은 전략과 기법을 고려할 수 있다. 비동기적인 방식으로 API 호출을 처리하여 응답 시간을 단축한다. 이를 통해 클라이언트는 여러 개의 API 요청을 병렬로 처리할 수..

<BFF> BFF에 대한 이해와 구현 1. 소개 * 개요 BFF(Baackend for Frontend)는 프론트엔드 개발자가 클라이언트와 백엔드 사이에서 인터페이스 역할을 수행하는 개념이다. 이번 포스팅에서는 BFF에 대한 개념과 구현 방법에 대해 다뤄볼 것이다. * BFF 개념 이해 - BFF는 "Backend for Frontend"의 약자로, 프론트엔드 개발자가 클라이언트와 백엔드 사이에서 인터페이스 역할을 수행하는 개념이다. 기존의 모놀리틱 아키텍처에서는 백엔드가 클라이언트의 요청을 직접 처리하는 구조였지만, 마이크로서비스 아키텍처에서는 백엔드가 여러 개의 독립적인 서비스로 분리되는 경향이 생기면서 BFF의 필요성이 대두되었다. - BFF의 주요 목적은 다음과 같다. 첫째, 클라이언트와 백엔드 간의 통신을 관리하고 처리하여 클라이언..

<FE> 프론트 엔드의 테스트 (with. Jest, testing-library) 1. 소개 - 소프트웨어 분야에서 테스트란 프로그램이 요구사항에 맞게 동작하는지 확인하는 것을 의미한다. 이러한 테스트를 통해 추후 발생할 문제들을 사전에 발견하고, 요구사항을 충족시키는지 확인할 수 있다. 게다가 코드를 수정하거나 개선하면서 생길 수 있는 부가적인 문제들을 확인하며 개발자는 어플리케이션의 품질을 보장할 수 있다. - 모던 소프트웨어에서 테스트는 상당히 발전하여 수많은 툴로 자동화를 할 수 있게되었다. 개발자가 직접 테스트를 하지 않고 라이브러리와 같은 툴의 도움으로 더 빠르고 정확한 테스트를 수행할 수 있다. 하지만 프론트엔드는 점점 복잡해지고 있을뿐만 아니라 프론트엔드 특성상 사용자와 격리된 환경에서 테스트를 작성하는 것이 쉽지 않다. - 이번 포스팅에서는 위와 같은 환경에서 프론트 ..

<FE> React-Query 의 필요성 1. 소개 * 기존의 상태관리 - 모던한 FE에서 상태를 관리하는 것은 필수이다. 단순한 체크여부 뿐만 아니라 다크모드, 인풋 값, 로딩상태, 에러상태, 눈에 보이는 리스트 데이터부터 눈에 보이지 않는 비동기적인 상태들 까지 상태 관리의 대상은 점점 커지고 있다. - 데이터의 관리가 점점 프론트로 넘어오고 있으며 실시간에 가까워진다는 얘기를 심심치않게 들을 수 있다. 만일 이러한 상태관리의 대한 내용과 역사가 궁금하다면 필자의 이전 글을 참고하길 바란다. 어쨌든 이런 상태들 중 오늘 할 내용은 주로 비동기 상태와 관련된 내용이다. - 예를 들어 SNS의 게시글이나 할일 목록을 생각해보자. 이들은 처음에 서버에서 받아와 관리되며, 주로 전역 store에 담기곤 한다. 이 상태들을 관리하기 위해 redux,..

<FE> 프론트 관점에서 맛보는 GraphQL 1. 소개 * GraphQL이란? - 최근 GraphQL을 아냐는 질문을 받은 적이 있다. 프론트엔드에서 백엔드와의 api 소통에 대해 얘기하다가 나왔던 것 같다. 그 때는 정말 아무것도 몰라서 대답하지 못했지만 이후로 관심이 생겨서 이렇게 맛만 보게 되었다. - GraphQL은 페이스북에서 2015년 공개한 "쿼리 언어"이다. gql이라고도 불리는 이 언어는 api를 위해 만들어졌다. 공부를 하면서 계속 sql과 혼동이와서 db에서 이게 어떻게 되지? 하는 의문을 계속 가졌는데, sql은 DB에서 데이터를 효율적으로 가져오는 언어이고 gql은 "클라이언트"가 서버로부터 데이터를 효율적으로 가져오는 언어임을 명심하자. - api하면 떠오르는 단어가 있다. "REST API". REST API가 있는데 g..

<FE> 프론트엔드 상태 관리와 역사 1. 상태관리란 * 소개 - 프론트엔드하면 상태관리라는 단어를 빼놓을 수 없다. 상태를 효율적으로 관리하고 보여 주는 것이 프론트엔드 역량의 핵심이라 해도 과언이 아닐 것이다. - 그렇다면 도대체 상태가 무엇이고, 상태가 왜 프론트엔드에서 중요할까. 이러한 필요성들이 어떻게 어떤 목표를 가지고 발전해왔을까. 오늘의 포스팅은 이런 고민에서 시작하게 되었다. * 상태란? - 프론트엔드에서 상태란 주로 유저 정보나 UI에 영향을 미치는 동적으로 표현되는 데이터이다. 특정 컴포넌트안에서 관리되는 로컬 상태와 여러 컴포넌트에서 관리되는 전역 상태로 구분지을 수 있다. 말로는 어려우니 아래의 예시를 보자. - 위는 필자가 최근 진행했던 프로젝트에서 할일을 보여주는 부분을 캡쳐한 것이다. 회사 내에서 개인이 자신의 ..

<JS> 클로저에 대한 고찰 (소개 / 활용 / 단점 / 메모리) 1. 소개 * 배경 - 최근 기업 면접을 다니며 가장 자주 받은 질문 중 하나가 클로저에 대한 질문이었다. 간단하게만 묻고 넘어가는 기업도 있었지만 내가 어디까지 생각해봤는지 물어보는 기업도 있었다. 그래서 클로저가 무엇인지부터 시작해서 깊이 있게 고찰해보려 한다. * 클로저란 - 클로저는 외부 변수를 기억하고 이 외부 변수에 접근할 수 있는 함수를 의미한다. 자바스크립트의 렉시컬 환경은 외부 렉시컬 환경을 가리키는 outer 가 존재한다. - 알다시피 자바스크립트는 렉시컬 스코프를 따르므로 식별자가 현재 스코프에 존재하지 않으면 선언된 위치를 기준으로 외부 환경에서 해당 변수를 찾는다. - 결과적으로 자바스크립트의 함수는 모두 클로저이다. function func() { const x = 10; ret..

<React> React Router Dom V6 도입기 1. 배경 최근 리액트라우터의 메이저 버전이 5에서 6으로 올랐다는 소식을 접했다. 바뀌어봤자 얼마나 바뀌었을까 싶었는데 생각보다 많은 것이 바뀌었고, 기존 프로젝트의 리액트라우터 버전을 올려보는 것도 재밌을 것 같아서 시도해보았다. 이번 포스팅에서는 기존 필자의 프로젝트에 도입하는 과정을 서술할 예정이다. 혹시라도 react-router-dom v6를 공부하고 싶어서 들어왔다면 빈약한 내용에 조금 실망할 수는 있지만 그래도 읽어본다면 도움은 되지 않을까. 흥미 외에도 도입하고 싶었던 이유는 번들 사이즈이다. 리액트라우터 v6로 올라가면서 번들사이즈가 현저하게 줄어들었다. minified 기준으로 28kB 에서 17kB 까지 줄어들었다. 프로젝트에서 수많은 리액트 라우터 기능을 쓰는 것이 아니므로 들이는..

<FE> 리액트 프로젝트에 무한스크롤 도입하기 배경 최근 진행한 프로젝트의 메인페이지에서는 리스트 형태로 유저의 할일 목록을 보여주고 있습니다. 단순 todo List라면 그 양이 적을 수 있으나, 해당 팀에서 유저가 할당받은 task 들도 함께 보여주므로 한 번에 받아오기에는 양이 많았습니다. 그래서 스크롤의 위치에 따라 데이터를 조금씩 받아오는 무한스크롤을 구현하기로 하였습니다. 고민 무한 스크롤 코드를 작성하기 전에 3가지 고민이 있었습니다. 첫째, 어떤 방식으로 언제 요청할 것인가 입니다. 처음에는 스크롤의 위치를 관찰하여 약 80%위치에 도달하면 api 요청을 보내는 방식을 생각했습니다. 그러나 이는 너무 많은 이벤트가 일어나고, 이를 조절하기위해 debounce 또는 throttle을 구현해야 했습니다. 게다가 브라우저는 offsetTop..

이전 1 2 다음

티스토리툴바