API는 인터페이스다 - 프론트 개발과 API

API는 인터페이스다. 왜냐하면 API는 Application Programming Interface이기 때문이다.

 

API는 인터페이스입니다. 그것이 Interface이니깐.

API가 인터페이스라는 것은 중요하다. 이 글은 프론트 개발에서 이러한 점을 활용하여 작업 대기 시간을 줄이는 것에 이야기 할 것이다. API라는 단어를 여러 의미로 사용하게 될 것 같다. 백엔드와 관련지어 API라는 단어가 나오는 것은, 주로 백엔드 구현체를 말하는 것이고, 그 외에는 대부분 API 명세를 말한다.

일반적으로 프론트 개발 과정에서 백엔드에 의해 작업이 lock되는 경우는 대부분 API의 구현을 기다리는데 쓰는 경우가 많다. 이런 루트를 타는 것이다. "백엔드 API가 나오지 않았다 → 프론트 모델을 짤 수가 없다 → 프론트 로직 작업은 백엔드 API 나올 때까지 대기"

하지만 API가 인터페이스라는 것을 생각하면, 백엔드의 API 구현을 기다릴 필요가 적다.

API 구현체 없이 프론트 개발이 가능할까?

간단한 예시를 통해 알 수 있다. 간단하게, 글을 저장하는 API를 만든다고 치자. 여기서는 보통 API하면 익숙한 웹 API를 개발한다.

규격은 HTTP Protocol을 이용한 REST 아키텍처를 사용하기로 정했다고 가정한다. 이 API를 정의하는 데 있어서 필요한 것은 어떤 것들이 있을까?

먼저, 요청경로와 HTTP Method를 정의해야 할 것이다. 경로는 /blog/post로, 메소드는 POST를 사용하기로 결정했다.

그다음으로는 RQ와 RS가 필요할 것이다. 여기서는 아래와 같이 정의했다.

 

 

API를 정의하는데 필요한 작업은 모두 끝났다. 이제 프론트 코드를 짜 보자.

 

이제 프론트 작업은 모두 끝났다. 프론트 모델링도 얼마든지 할 수 있다.

백엔드를 기다리지 않고 프론트 작업하기

이처럼 API를 정의하면, 그때부턴 프론트는 백엔드 서버가 API를 제공하지 않는 상황이더라도 작업을 진행할 수 있다. 프론트도, 백엔드도, 위에서 정의한 인터페이스로 데이터를 주고받을 것이기 때문이다. 프론트는 백엔드의 구현체가 Java인지, Node.js인지 신경 쓰지 않아도 된다. Go, Rust, PHP등 어떠한 언어를 사용해도 무방하다. 중요한 것은 위에서 정의한 인터페이스이기 때문이다.

꼭 지금 axios로 개발해야 할까?

백엔드가 없는 상황에서 axios로 백날 리퀘스트를 보내도, 돌아오는 건 404밖에 없다. 404만 해결되면 런타임에서도 잘 실행될 수 있다. 플로우를 태우면서 테스트를 해보고 싶은데, 백엔드가 개발될 때까지는 시간이 좀 더 걸릴 것 같다. 이런 상황에서는 어떻게 해야 할까. 이해를 위해 비유를 들자면, 집집마다 파이프를 죄다 연결해놓았는데, 정작 수도 공급이 안 되는 상황이다. 

백엔드가 없으면 프론트가 하면 되지

솔직히 postId를 number로 했어야 했는데..

axios 쓴 부분은 그냥 주석처리한다. 이제 404 오류를 보지 않고도 개발을 할 수 있게 됐다. 

테스트를 돌렸더니, 잘 돌아간다! 이제 프론트가 할 일은 끝났다. 백엔드 API가 개발될 때까지 기다리면 된다. 백엔드 API가 연동되면 혹시나 모를 버그를 방지하기위해 다시 한 번 더 테스트 하면 된다.

언제 바뀌었죠?

백엔드가 실제로 모델링을 하면서 RQ와 RS가 바뀔 수 있다는 것을 조심해야 한다. 너무 이른 시기에 정하게 되면 바뀔 수도 있다. 프론트 모델링과 일치하는 것이 좋겠지만, 바꿀 시간이 부족한 경우가 있을 수 있다. 단순한 필드명 같은 경우에는 그냥 적절하게 이름을 바꿔 return 해주는 방법을 사용할 수도 있다.

아, 이게 안되네. API 차이 수준

위에서 이야기한 것들은 전부다 JSON으로 왔다 갔다 하는 API의 경우다. 이런 경우에는 정말 깔끔하게 마무리할 수 있겠지만, 그렇지 않은 경우도 종종 있다. Raw 데이터가 왔다 갔다 할 수도 있고, 백엔드와 연결과정에서 버그들이 잔뜩 나올 수도 있다. 하지만 예외적인 경우가 아니라면, API 정의를 빠른 시점에 함으로써 대기시간을 줄이는 것은 어떨까?

이 글이 말하고자 하는 내용을 요약하시오 (5점)

• 가능한 경우에 RQ와 RS를 빠른 시점에 정의함으로써, 프론트 개발자가 백엔드 API 구현에 의존하지 않는 것이 좋다.
• 인터페이스를 통해 구현체를 다양하게 구성할 수 있도로 하면 좋다.

여담

TDD처럼 IDD(Interface-Driven-Development) 같은 단어를 만들면 어떨까 싶었다. 느낌은 대충 위에서 언급한 것을 좀 잘하는 느낌? 그런데 현실은 비슷한 게 이미 있었던 거 같다. (en.wikipedia.org/wiki/Interface-based_programming)

 

이 글은 전부 폰트가 Pretendard로 되도록 했는데, 매우 만족스럽다. Pretendard 폰트에 대한 이야기는 조만간 하지 않을까 싶다.