backend 와 통신하기 위한 api 를 캡슐화

[irrationnelle]

현재 상황

• firebase 를 backend 로 사용
• CRUD 작업은 모두 firebase 에 의존
• 이미지 업로드 및 이미지 url 을 참조하는 것도 firebase 의존
• 캡슐화를 위해 분리한 api 파일 내부에서도 firebase 의존
• firebase 를 전역적으로 사용

변경하고 싶은 부분

• firebase 를 전역적으로 사용하지 않기
  • 타이핑 정보를 몰라서 firebase 를 전역적으로 사용했지만 이제는 firebase 를 init 단계에 초기화하고 타이핑하여 앱에 전달 가능
• api request 가 firebase 에 의존하지 않기
  • 요약하면, firebase 를 걷어내고 이후에 axios 등을 사용하여 http 로 호출하는 방식으로 변경해도 인터페이스는 유지하고 구현만 변경하고 싶음.
• react 라이프 사이클 및 props 전달 방법으로 api 사용하지 않기
  • firebase 를 전역적으로 사용하지 않으면 초기화한 firebase 인스턴스를 api 파일에 전달해야 한다.
  • 이 api 전달을 위해 api 파일이 react 내부 라이프사이클과 결합하면 나중에 react 와 분리하기 어려워진다.

[irrationnelle]

해결방법 첫번째

API 요청을 담당하는 정적 클래스를 만든다.

장점

• 정적 클래스이기 때문에 초기화를 보장한 이후에는 현재 firebase 를 전역적으로 사용하는 것처럼 간편하게 사용 가능하고 react 의 라이프사이클에 영향을 받지 않음

단점

• 인스턴스 생성을 하지 않고 전역적으로 정적 클래스의 메소드를 호출하는 방식이기 때문에 초기화 시점을 보장할 수 없고 이로 인해 버그가 발생할 수 있음.
• 정적 클래스를 사용하기 때문에 생성자에 api 호출의 core 요소를 전달하는 방식은 사용 불가능
  • 예를 들어 일반적인 클래스를 사용하면 생성자에 초기화를 끝낸 firebase 개체 등을 전달할 수 있다.

[irrationnelle]

해결방법 두번째

API 요청을 담당하는 클래스를 만든다.

장점

• 생성자 인자로 firebase 등의 api 요청에 꼭 필요한 개체를 전달할 수 있어서 캡슐화가 용이
• 인스턴스 생성을 통해 초기화 시점을 확실하게 알 수 있음

단점

• 생성한 인스턴스를 api 요청 파일이 사용할 수 있는 방법을 따로 고민해야 함.

[irrationnelle]

결정

첫번째 방법을 선택. 하지만 정적 클래스로 만들지 않고 현재 구조처럼 파일을 나누어서 개별적으로 export 한다.

이유

• 기존에 axios 등으로 http 요청을 할 때도 axios 를 전역적으로 사용하기 때문
• firebase 를 그럼 현재 상태 그대로 사용할 수 있으나 firebase 에 의존적인 모습을 벗어나기 위해 함수로 한 번 감싼다.