
안녕하세요.

오늘은 제가 올해 초 진행했었던 [유튜브 뮤직 클론코딩 프로젝트](https://github.com/devDohyun/clone-youtube-music)를 리팩토링하면서  
개선이 필요한 코드를 발견하여 수정한 경험을 공유해보고자 합니다.

![ex_screenshot](/post/210613_0.png)

해당 페이지에서는 `nested router`를 통해 재생목록, 앨범, 노래, 아티스트, 구독 탭을 보여주고 있습니다.  
url에 child route를 입력해주지 않은 경우 탭에서 아무것도 보여주지 않아 리다이렉트를 시켜주고자 했었던 것 같습니다.  
여기서 문제는 ... 아래처럼 `mounted` 훅에서 검사를 시켜주고 있었네요 ...

```javascript
methods: {
  gotoDefault() {
      if (this.$route.path === '/library') this.$router.replace('/library/playlists')
  }
},
mounted() {
  window.scrollTo(0, 0)

  this.gotoDefault()
}
```

`route`의 검사를 `mounted` 훅에서 진행하다보니 가끔씩 화면이 플리커링 되는 현상도 있었습니다.  
당시에는 어쩔 수 없는가보다 싶었는데, 지금보니 왜 이렇게 했나 싶네요... 반성해야겠습니다 ......ㅎㅎ

솔루션은 간단합니다.

조금 더 빠르게, 그리고 플리커링을 방지하기 위해서는  
Lifecycle상 페이지 컴포넌트의 create보다 빠른 middleware에서 검사를 해주도록 하였습니다.

## 1\. 적용하기

기존의 소스코드를 삭제하고 아래처럼 middleware를 사용하도록 합시다.

```javascript
middleware({ route, redirect }) {
  if (route.fullPath === '/library') return redirect(`/library/playlists`)
},
```

`middleware`를 통해 검사하게 되면, serverside에서 리다이렉션이 작동하게 되어
이슈가 해결된 것을 확인할 수 있었습니다.



프론트엔드 개발자의 경우,  
가끔 백엔드의 API Response 값이 `snake_case`일 경우 어떻게 관리할 지에 대해 고민에 빠지게 됩니다.

저도 오늘 같은 상황을 겪게 되었는데,  
이번엔 네이밍 컨벤션을 맞춰주기로 했습니다.

컨벤션을 맞추는 데에는 여러가지 방법이 있겠지만,  
고민 끝에 저는 `axios`의 `interceptor`를 통해 해결을 해보았습니다.

## 1\. 적용하기

전체적인 프로세스는 두 가지입니다.  
하나는 공용으로 사용하는 instance에 `interceptor`를 붙이는 것,  
하나는 넘겨받은 object의 key들을 `CamelCase`로 변경하는 함수를 작성하는 것이 되겠습니다.

먼저 `interceptor`를 붙여봅시다.

```javascript
import axios from 'axios'

const client = axios.create({
  withCredentials: true,
})

client.interceptors.response.use((response) => {
  response.dataOriginal = JSON.parse(JSON.stringify(response.data))

  return response
})

export default client
```

혹시 모를 경우를 위해 오리지널 데이터를 따로 복제해둡시다.  
이번엔 object의 key들을 `CamelCase`로 변경하는 함수를 작성해보겠습니다.

```javascript
export const objectKeysToCamelCase = (ob = {}, isDeep = true) => {
  return Object.entries(ob).reduce((acc, [key, value]) => {
    const keyComputed = key.replace(/(_.?)/g, (matches) => matches[1].toUpperCase())

    let result

    if (isDeep === false || !value || typeof value !== 'object') {
      result = value
    } else if (Array.isArray(value)) {
      result = value.map((item) => objectKeysToCamelCase(item, isDeep))
    } else {
      result = objectKeysToCamelCase(value, isDeep)
    }

    acc[keyComputed] = result

    return acc
  }, {})
}
```

저는 유틸리티성 함수들을 따로 모아 관리하고 있어서 `export`가 포함되어있는데,  
만약 하나의 파일에서 진행하신다면, 굳이 넣지 않으셔도 됩니다.

함수를 조금 설명하자면, API Response 값의 경우 대부분 여러 depth가 존재할 텐데, 이를 위해 재귀함수로 구성하였습니다.

만약 2번째 파라미터인 isDeep이 참이라면,  
depth 1 뿐만 아니라 하위 depth까지 object가 존재하는지 탐색하고 key의 컨벤션들을 `CamelCase`로 변환시켜줍니다.

반대로 거짓일 경우엔 depth 1의 key 값들만 변환시켜주겠지요 ?

이렇게 네이밍컨벤션을 변환해주는 함수를 만들었다면, 아래와 같이 적용시켜줍시다.

```javascript
import axios from 'axios'

import { objectKeysToCamelCase } from '../util'

const client = axios.create({
  withCredentials: true,
})

client.interceptors.response.use((response) => {
  response.dataOriginal = JSON.parse(JSON.stringify(response.data))

  response.data = objectKeysToCamelCase(response.data)

  return response
})

export default client
```

그 후 확인해보면,

![ex_screenshot](/post/210611_0.png)

적용이 잘 된 것을 확인해볼 수 있습니다.

하지만 여기서 뭔가 찜찜한 기분이 드는데,

퍼포먼스에 대한 이슈입니다.

아무래도 모든 요소의 key와 value를 탐색하고, 비교 한 뒤 새로운 객체를 생성하는데, 걱정이 안 될 수가 없습니다.

그래서 한번 ... 테스트를 시도해보았습니다.

## 2\. 퍼포먼스 테스트

```javascript
import axios from 'axios'

import { objectKeysToCamelCase } from '../util'

const client = axios.create({
  withCredentials: true,
})

client.interceptors.response.use((response) => {
  console.time()

  response.dataOriginal = JSON.parse(JSON.stringify(response.data))

  response.data = objectKeysToCamelCase(response.data)

  console.timeEnd()

  return response
})

export default client
```

단순히 response가 도착한 후 `interceptor`가 받아 들일 때부터 넘겨줄 때까지의 시간을 재어봤는데요.

![ex_screenshot](/post/210611_1.png)

다행히도 이 과정에 0.017초 가량 소요된 것을 알 수 있었습니다.



안녕하세요.  
오늘은 Maria DB 초기 세팅 시, 외부에서 접속이 안될 때 매뉴얼을 작성해보겠습니다.

## 1. 들어가며

사용하실 계정의 Host를 잘 설정해주셨는데도 만약 외부에서 접속이 안되신다면,  
인바운드가 불가능한 것으로 추측해볼 수 있습니다.

## 2. 작업하기

먼저 사용중이신 서버의 터미널에 `netstat -lntp`를 입력해봅시다.

입력하면 아래 이미지처럼 사용중인 포트의 목록이 뜨는데,

![ex_screenshot](/post/210714_0.png)

만약 mysqld 프로세스의 ip가 `127.0.0.1:3306`로 잡혀있다면,  
내부에서만 접속이 가능한 상태입니다.

이는 간단하게 config를 수정하여 대응이 가능합니다.

maria DB의 경우 `/etc/mysql/mariadb.conf.d/50-server.cnf` 파일을 수정해 주시면 됩니다.

vi를 통해 위 파일을 여신 후 `bind-address`라는 키워드를 검색해보시면 127.0.0.1로 되어있는 것을 확인할 수 있습니다.

이를 아래 처럼 수정해주세요.

![ex_screenshot](/post/210714_1.png)

수정을 하셨다면 저장 후 서비스를 재실행 해주시면 됩니다.

그럼 잘 접속되는 것을 확인 하실 수 있습니다.


nested router의 기본 route 지정해주기

1. 적용하기