생각해보기🤔 - 장바구니

 

🛒 Flux는 MVC의 어떤 문제를 해결했을까?

MVC는 복잡한 의존성과 양방향 데이터 흐름이라는 문제가 있었다.

이를 해결하기 위해 Flux가 만들어졌다.

 

1. 중앙 집중화된 데이터 스토어

MVC 패턴의 여러 모델 대신, Flux는 중앙 집중화된 데이터 스토어를 사용한다.

이를 통해 데이터 일관성을 유지하고 유지 보수를 용이하게 한다.

 

2. 단방향 데이터 흐름

Flux는 데이터를 단방향으로 흐르게 하여 구조를 단순하게 만든다.

데이터는 액션(Action) -> 디스패처(Dispatcher) -> 스토어(Store) -> 뷰(View) 순서로 흐른다.

이를 통해 상태 관리를 좀 더 예측 가능하게 하여 디버깅을 쉽게 만든다.

 

 

🛒 이전 미션에서와 같이 React 자체에서 제공하는 방법으로만 상태를 관리하는 것에 비해 어떤 장점이 있을까요?

1. 확장성

외부 라이브러리 사용 시 애플리케이션의 규모가 커질수록 상태 관리가 더 효율적이고 간편해진다.

 

2. 예측 가능성

외부 라이브러리 사용 시 상태 변경 로직을 통합하여 관리할 수 있다.

이 경우 상태 변화를 예측하기 쉬워지며 디버깅하기 용이하다.

 

3. 모듈화 및 재사용성

상태 관리 라이브러리 사용 시 상태 관련 로직을 별도의 모듈로 분리할 수 있다.

이 경우 코드 재사용성이 높아지며, 유지보수하기 용이하다.

 

 

🛒 서버 사이드 라우팅으로 할 수 없는, 클라이언트 사이드 라우팅의 장점이 있을까요?

1. 빠른 페이지 전환

클라이언트 사이드 라우팅(이하 CSR)에서는 모든 페이지와 자원을 한 번에 불러와 브라우저에 저장한 후 필요할 때 바로 사용한다.

이는 페이지 전환시마다 서버에 요청을 보내고 응답을 기다릴 필요가 없게 해 화면 전환 속도가 빠르다.

 

2. 부드러운 사용자 경험

CSR은 페이지 전환 시에 전체 페이지를 새로 렌더링 하지 않고 필요한 부분만 업데이트한다.

이로 인해 사용자에게 더 부드러운 경험을 제공하고 더 나은 성능을 얻을 수 있다.

 

3. 서버 부하 감소

CSR을 사용하면 전체 페이지를 렌더링 하는 데 필요한 데이터와 파일을 서버에서 내려받을 필요가 없다.

이로 인해 서버의 부하를 줄일 수 있으며, 서버 자원을 효율적으로 관리할 수 있다.

 

4. 오프라인 접근 가능

CSR은 모든 페이지와 자원을 브라우저에 저장해 두기 때문에, 네트워크 연결이 끊긴 경우에도 일부분 사용할 수 있다.

 

 

반면, CSR의 단점 또한 있다.

 

1. 초기 로딩 시간 증가

CSR은 애플리케이션의 모든 페이지와 자원을 한 번에 불러오므로 초기 로딩 시간이 길어질 수 있다.

 

2. 검색 엔진 최적화(SEO) 문제

검색 엔진이 CSR에서 자바스크립트를 실행하지 않거나, 제대로 실행하지 못하면 문제가 발생할 수 있다.

 

 

🛒 클라이언트 사이드에서 라우팅을 적용할 때, 대응해야 하는 케이스에는 어떤 것들이 있을까요?

1. 기본 라우팅 설정

애플리케이션에서 사용될 각 경로 및 컴포넌트를 설정해야 한다.

 

2. 중첩된 라우팅

동적으로 중첩된 라우트를 처리하는 방법을 고려해야 한다.

 

3. 동적 라우팅

경로에 포함된 변수를 사용하여 해당 변수가 변할 때마다 동적으로 페이지를 렌더링 하는 방법을 적용해야 한다.

 

4. 인증 및 권한 체크

사용자의 로그인 상태나 권한에 따라 접근할 수 있는 페이지를 제한하거나 허용해야 한다.

 

5. 에러 페이지

존재하지 않는 경로나 제한된 경로에 접근하려는 경우에 대응하는 에러 페이지를 구현해야 한다.

 

6. 검색 엔진 최적화

CSR의 경우 검색 엔진 크롤러가 동적으로 생성되는 페이지를 인식하지 못할 수 있기 때문에 SEO를 위한 메타 데이터를 적절하게 처리해야 한다.

 

7. 페이지 이동 시 스크롤 행동

페이지 전환 시마다 새로운 페이지의 상단부터 시작하도록 브라우저 스크롤 위치를 갱신하거나 다른 스크롤 동작을 처리해야 한다.

 

 

🛒 MSW는 실제 백엔드 서버 없이 클라이언트-서버 간의 상호작용을 모킹 할 수 있게 해 줍니다. 이로 인한 장단점은 무엇이 있을까요?

장점

1. 개발 효율성 향상

백엔드 서버 개발이 완료되지 않은 상태에서도 클라이언트 측 로직을 개발할 수 있다.

따라서 프론트엔드와 백엔드가 독립적으로 작업을 진행할 수 있고, 전체 프로젝트의 개발 속도를 높일 수 있다.

 

2. 테스트 용이성

MSW를 통해 실제 백엔드 서버에 의존하지 않고 간단하게 API를 모킹 하여 테스트 케이스를 작성할 수 있다.

 

3. 개발 환경에서의 일관성

모킹 데이터를 사용하면 언제든 동일한 데이터와 결과를 확인할 수 있다.

 

4. 오프라인 개발 가능

인터넷 연결이 되지 않는 환경에서도 모킹 된 데이터를 사용하여 작업을 진행할 수 있다.

 

단점

1. 실제 서버와 동기화 문제

API 명세가 변경되거나 새로운 기능이 추가되면, MSW에서 관리하는 모킹 데이터를 수동으로 업데이트해야 한다.

이 과정에서 실제 서버와의 동기화 문제가 발생할 수 있다.

 

2. 오류 발견 지연

MSW로 모킹 된 API를 사용하다 보면 실제 백엔드 서버의 오류를 찾아내기 어려울 수 있다.

 

3. 초기 구축

처음에 MSW를 설정하고 모킹 API를 구축하는 과정이 비교적 복잡할 수 있다.

 

 

🛒 MSW를 사용하지 않고 프론트엔드 개발 과정에서 API 테스팅을 진행할 다른 방법은 무엇이 있을까요? 그리고 그 방법들과 MSW를 비교하였을 때 MSW의 장점은 무엇일까요?

1. Axios Mock Adapter

Axios Mock Adapter를 사용하면 Axios 요청을 가로채고 모킹 된 응답을 반환할 수 있다.

 

2. Jest Mock Functions

Jest를 사용할 경우, jest.mock() 함수를 사용하여 모듈을 모킹 하거나, jest.fn() 함수를 사용하여 모든 API 호출의 모킹 된 함수를 정의할 수 있다.

 

3. Nock

Nock은 HTTP 요청을 가로채고 모킹 된 응답을 반환하는 라이브러리이다.

 

4. Sinon.js

Sinon.js는 JavaScript 테스팅 라이브러리로, 스텁(stubs), 스파이(spies) 및 목(mock) 기능을 제공하여 API 호출을 모킹 하고 테스트할 수 있다.

 

위 방법들과 MSW를 비교하였을 때, MSW 장점은 아래와 같다.

 

1. 서비스 워커 사용

MSW는 서비스 워커를 사용해 실제 요청을 가로채서 모킹 하기 때문에, 동일한 방식으로 실제 API로 전환할 수 있다.

따라서 실제 네트워크 트래픽이나 요청을 모킹 하는 것에 가까운 환경을 제공한다.

 

2. 라이브러리 프레임워크에 독립적

MSW는 특정 테스트 라이브러리나 프레임워크에 종속되지 않는다.

 

3. 테스트와 개발 환경에 모두 사용 가능

MSW는 테스트 환경뿐만 아니라 개발 환경에서도 사용할 때 일관성 있는 모킹 경험을 제공한다.

 

4. API 변경에 유연한 대처

MSW를 사용하면 API 명세가 변경되거나 새로운 기능이 추가될 때, 간단한 업데이트를 통해 최신 상태를 유지할 수 있다.

 

 

🛒 프론트엔드 개발자는 MSW를 어떻게 더 효율적으로 활용할 수 있을까요?

1. 요청 처리 전략

각 API에 대한 모킹 응답을 계획할 때, 다양한 요청 처리 전략을 세워보자.

예를 들어 일부 요청에 대한 실패 응답을 생성해 에러 처리를 개선할 수 있다.

 

2. 응답 지연 시뮬레이션

응답 지연 시간을 지정하여 네트워크 지연 및 요청 실패에 대응하는 로직을 테스트할 수 있다.

 

3. API 정의 및 문서화 공유

API를 정의하고 문서화한 것을 공유하고 중앙화하여 관리하는 것이 좋다.

이렇게 하면 프로젝트 내 다른 부분에서도 활용 가능하며 실수를 줄일 수 있다.