📚금일 학습 내용
월요일부터 강의 정리가 없는 이유는 강의를 듣기 만 했고 정리하지 않았기 때문이다. 왜냐하면 API 발표 흐름을 결국 또 뒤엎었고... 다시 플로우를 구성하고 PPT를 만들고 있기에... 생각보다 스트레스가 심하다. 여튼 그래도 오늘 들었던 건 다양한 컴포넌트 연습 사례이다.
🤔 Axios 어떻게 쓰는거지..?
오늘도 역시 에구마 선생님의 질문으로 시작이 되었다. 늘 리스펙...
근데 왜 예구마가 아니라 에구마지? 급 궁금🤔
질문의 핵심 요지는 다음과 같았다. axios.post로 보내는 코드가 왜 정상적으로 axios.get요청이 된 것 처럼 return이 오는가? 였다. 처음 봤을때는 이게 왜 동작하는 거지? 라는 의문이 들었다. 심지어 충격적이고 심각했던 건 put, delete로도 값이 돌아왔다는 것이다. 상식적으로 생각해보자. 나는 분명 axios.get이 아닌 코드로 실행했다. 하지만 막상 돌아온 값은 get값이 왔다. 이거야 말로 비둘기짤 아닌가?
대체 왜 동작하는 건데!!! 아니면 아래 같은 그런 느낌인...
일단 이 문제에서 전제조건 한 가지가 있다. 바로 서버리스의 존재이다. axios.post를 호출하면 그 자리에서 바로 url링크를 통해 API를 통신을 하는 것이 아니라. api폴더에 구성된 서버리스 형태의 API를 호출한다. 따라서 내가 정리한 의견은 다음과 같다.
API 호출 구조가
- 스토어에서 fetchMovies로 함수 호출을 하면
- 바로 axios.post가 동작하는 것이 아닌, axios.post로 /api/movieList에 호출이 가고
- 이후 /api/movieList 내부 로직이 실제 omdb API를 호출해 상호작용 후 반환값을 주는 형식
이렇게 되어있는데 여기서 핵심은 내부에서만 동작하는 1->2로 호출하는 과정에서는 post형식이지만 결국 막상 2->3에서 호출하는, 즉 실제 omdb쪽에 요청은 get으로 들어가는 거라고 생각된다.
즉 외부에서 api를 호출하는 함수가 동작하긴 해도 결국 동작하는 것은 아래 코드라는 뜻이다.(참고로 await axios({}) << 이런 형식이면 기본 값인 GET 형식으로 호출된다.)
const { data: responseValue } = await axios({
url: `https://omdbapi.com/?apikey=${API_KEY}&s=${title}&y=${year}&page=${page}`,
method
})심지어 심각했던 것은 axios.post뿐만 아니라 put을 넣어도 동작했고 delete의 경우도 데이터 형식을 맞춰주니 정상적으로 동작했다. 음.. 내용이 너무 중구난방인 것 같은데 코드로 정리해보자
// 데이터를 관리하는 부분에서 API를 호출하는 함수
// 보다시피 바로 url주소로 호출하는 것이 아닌 api 폴더에 존재하는 특정 로직을 호출하는 형식이다.
// 또한 메서드가 delete임을 확인할 수 있다.
async fetchMovies(title: string) {
... 중략
const { data } = await axios.delete('/api/movieList', {
data: {
title,
page: this.page.toString()
}
})
... 후략
// api 폴더에 있는 실제 api를 호출하는 ts파일
// 이 쪽 코드에서 실제 url 주소가 삽입되어있고 결국 실질적으로 API를 호출하는 동작은 이 파일에서 진행된다.
// 그리고 200응답이 오면 결과를 반환해준다.
export default async function (req: VercelRequest, res: VercelResponse) {
... 중략
const { data: responseValue } = await axios({
url: `https://omdbapi.com/?apikey=${API_KEY}&s=${title}&y=${year}&page=${page}`,
method
})
res.status(200).json(responseValue)
}충격적이지 않은가? 나는 개인적으로 굉장히 충격적이고 위험할 수 있다는 느낌을 받았다. 만약 이런식으로 동작되는 코드가 있다면, 그리고 이 코드를 처음보는 개발자의 입장에서 매우 헷갈리지 않을까? 하는 생각이 있다. 물론 내가 주니어라 잘 모르지만.. 지금의 느낌은 그렇다.
그리고 이제 이번 주제인 Axios 어떻게 쓰는거지..? 이다. 이 질문이 나에게, 아니 정확히 나에게 온 건 아니지만 우리 팀에 왔던 이유는 다음과 같았다.
// 이 코드와
const { data } = await axios.post("/api/getMovieData", null, {
params: { s, page: 1 },
});
// 이 코드의 차이
const { data } = await axios.post("/api/getMovieData", {
params: { s, page: 1 },
});위처럼 2가지 차이점이 발생했는데, 이렇게만 보면 다른점을 빠르게 캐치할 수 있을거라고 생각한다. 바로 인자에서 null의 유무이다. 이 질문을 줬던 예진님은 바로 저 차이 때문에 문제를 캐치하지 못했고 나 또한 처음에는 뭐가 문제이지 라는 생각이 들었다. 내가 힌트를 얻었던 것은 바로 axios.delete의 동작 방식이였다.
axios.delete를 사용하면서 알게된 것은 2번째 인자에서 data를 한번 감싸줘야한다는 것이였다.
axios.delete(`${url}/unlike`, {
data: {
projectId: id,
},
})즉 axios에서 인자를 사용할때는 무언가 axios만의 규칙이 있을 것이라고 생각되었다. 아니나 다를까 해당하는 내용을 찾아보니 axios.post(url[, data[, config]]) post는 이런식으로 데이터를 받았다. 즉 여기서 옵션의 형태인 params를 담으려면 2번째 인자인 data가 아닌 3번째 인자인 config에 입력해야 하므로 axios.post("/api/getMovieData", null, { params: { s, page: 1 }, }) 이렇게 감싸줬어야 했다.
axios는 분명 좋은 라이브러리이다. 이미 수 많은 사람이 사용하고 있고, fetch와 비교했을 때 장점이 많은 라이브러리이다. 하지만 처음 접하는 입장에선 사용법이 친절하지 않다. 특히 공식문서가 초심자의 입장에서는 친절하지 않다. 특히 우리가 경험했던 것처럼 잘 알지 못하고 쓰면 오히려 fetch로 처리하는 것보다 시간을 낭비할 가능성이 매우 높았다.
마무리가 조금 애매한데, 여기서 내가 언급하고 싶은 것은 axios가 좋지 않다 혹은 axios를 사용하면 안된다. 라는 것이 아니다! 잘 공부하고 쓰지 않으면 안 쓰는 것만 못하다. 라는 것이다. 적어도 오늘 나와 나의 팀원들이 얻은 결론은 그렇다.
추가적으로 나의 의견을 조금 첨언하자면 알고 data와 params의 차이 등 기초적인 네트워크 공부가 보완되면 좋을 것 같다고 생각한다. 나 역시 vue 과제를 하면서 api 연결을 하며 request, params, body, query 등에 대한 학습을 진행하니 조금이나마 검색 키워드를 추측할 수 있었는데 만일 그러지 않았다면 나 역시도 이 문제를 아직도 고민하고 있었을 것이다.
우리 팀원들은 학습에 대한 면에서 나보다 캐치가 빠르다. 이런 이야기 직후 바로 Axios 관련해서 깔끔하게 정리된 관련 블로그를 찾아서 링크를 공유해주었다.
axios.request(config)
axios.get(url[, config])
axios.delete(url[, config])
axios.head(url[, config])
axios.options(url[, config])
axios.post(url[, data[, config]])
axios.put(url[, data[, config]])
axios.patch(url[, data[, config]])학습의 길은 멀고도 험하다. 하지만 같이 학습하니까 즐겁기도 하고 일이 잘 풀리는 것 같다. 하지만 많이 데이고 나서는 항상 드는 생각이 내가 맞을까..?이다. 오늘도 뭔가 결론은 냈지만 항상 의심을 버리지 말자.
💭면담
재미있었습니다! 그리고 감사합니다!!
드디어... 기다리고 기다리던 소피아 매니저님과 면담을 진행했다. 하고 싶은 말도, 듣고 싶은 말도 많았던 면담이였는데 시작부터 내 예상과 정반대의 이야기를 해주셨다. 나는 매운맛 피드백을 요청드렸는데 매니저님의 답변은 다음과 같았다. 이미 잘 하고 계셔서 딱히 드릴 말이 없는데요..? 였다. 그리고 나서 계속 칭찬을 해주셔서 기분이 좋았다. 특히 우리 돌돌현들에 대한 칭찬을 많이 해주셨는데 우리가 열심히 하는 것을 알아주는 사람이 있다는 것만 해도 행복했다.
그리고 내가 제일 궁금했던 나를 뽑아주셨던 이유에 대해서도 여쭤봤다. 여기서 조금 매운맛을 받긴했는데 객관식 문제가 쉬웠는데 결과가 아쉬워요...^^라고 매우 완곡하게 표현해주셨다ㅋㅋㅋ 그래도 나의 서류와 면접에서 정말 좋은 평가를 주셨고 자신감을 얻을 수 있었다. 대학교 입시때부터 서류만 뚫으면 항상 면접은 자신있었는데 여전히 나의 면접 준비 방식이 유효하다는 확신을 얻을 수 있었고 일부 보완한다면 추후 취업 면접에서도 나의 강점이 충분히 드러날 수 있겠다 라는 생각이 들었다.
이외에도 많은 TMI와 오프 더 레코드를 매니저님과 이야기하면서 예정 시간의 3배인 1시간 30분동안 이야기를 했는데, 너무 즐거웠다. 매니저님의 생각도 많이 알 수 있었고, 드리고 싶었던 말씀도 다 드렸다. 항상 텍스트 통신보다는 대화로 해야할 말들이 있는데 그런 시간을 가져서 좋았다.
📖소회
중간 중간 스트레스 풀겸 동기들을 던져주는 문제를 해결하는게 오히려 마음이 편할정도로 스트레스를 받는다. 왤까.. 도대체 왜일까... 나도 나를 모르겠다. 거기다가 요 스트레스랑 다른 요소는 또 별개다ㅋㅋㅋㅋ 막상 면담하면서 자신감도 많이 얻고 기분이 좋았는데 이건 또 별개의 문제같은 느낌이다. 막상 조사를 하니 너무 쉬운 API라고 생각되서일까? 모르겠다. 이제 한 36시간 남았는데 최선을 다해보자🔥🔥🔥
TIL 작성 소요시간 약 40분
