• issue #19

• pr #21

• 위 이슈에 대한 후속 처리.

• static server로 저장된 file에 대한 meta정보들을, voda cloud sql로 저장시킨다.

how i write my unit tests in go quickly

논의 이슈

GET /v1/alarms

Diary API

1. Gather error code together
2. Returns common format

{
  code: str,
  message: str,
  data: {}
}

@minkj1992

#22 에 대한 후속 처리

작성 순서 GET api

• request/ response
• panic auto filter
• stack trace

deviceToken 관련 refs

voda 정책

• POST /token 요청을 보낼때, authCode랑 deviceToken(string)을 클라에서 준다.

• 서버에서는 authCode의 유저가 deviceToken을 기존에 db에 저장하고 있지만, post로 전달 된 deviceToken을 가지고 있지 않는다면 다중 디바이스로 간주하고 추가.

• 이후 서버쪽에서 파이어베이스(FCM)로 메시지 보낼 때, 토큰 만료 메시지 받는 경우에는 해당 deviceToken은 만료되었다고 간주하고, 삭제

ginko
godog (support by cucumber)

ginko

• https://semaphoreci.com/community/tutorials/getting-started-with-bdd-in-go-using-ginkgo
• https://medium.com/lensesio/declarative-bdd-with-golang-3f5f6a1ac5a8

godog

• https://semaphoreci.com/community/tutorials/how-to-use-godog-for-behavior-driven-development-in-go

GET /v1/members/verify?nickname=%s

google cloud task에서 아래 TASK특성

1. task는 update할 수없다. 즉 immutable하다.
2. 명시적 TaskID에 대해서, 1시간 이상 Id가 저장된다. 이는 task를 delete하더라도 유지된다.

으로 인해, 아래 방향으로 커밋을 수정해야함.

1. 다이어리방의 period를 수정하더라도, 다음 턴 부터 잗성주기가 적용된다. (원래 스펙이며, 1hr 제약조건을 만족한다.)
2. 1을 위해서 delete -> create task 과정을 진행하는 코드는 제거한다 (UpdateTask 스펙)

@jun108059

google cloud run은 기본적으로 stateless container이다. 즉 컨테이너가 상태를 들고 있으면 안된다.

즉 alarm을 실행하기 위한 워커를 백그라운드에서 실행 하든지, google cloud storage와의 connection을 들고있는 client를
gin 서버 init 시점에 들고 있으면 안된다는 뜻이다.

local에서 실행 할 때는 물론 로컬에서 cloud run을 대신해서 프로세스가 돌고 있었기 때문에, 문제가 없지만, 분명 cloud run에 배포가 되고 request가 유지가 되지 않는 시점에 파일 업로드 api 요청을 보내면 문제가 생길 듯하다.

우선 이런 가정만 해두고, 문제가 생기면 issue를 해결하도록하자.

해결방법은 느려지긴 하지만, google storage client에게 request가 들고있는 context를 주든지, 아니면 context.background()를 주는 방법이 있을 듯하다.

@Doyuni

local(=dev)

로컬에서 go 서버 실행 및 로컬 db에서 실행

• api 서버
  • local runtime go file
• db
  • local mysql
• db-proxy
  • x

$ make run

sandbox

docker compose 기반으로 로컬에서 실행가능

• api 서버
  • local docker image
• db
  • google cloud sql (remote)
• db-proxy
  • local docker image

$ make down && make up

prod

실제 배포할 서버

• api 서버
  • google cloud run (exchange-diary)
• db
  • google cloud sql (remote)
  • sandbox 페이즈에서 사용하는 db와 동일한 db를 바라본다. (돈 때문에)
• db-proxy
  • google쪽에 세팅해둠
• build
  • google cloud-build를 사용해서, cloudbuild.yml에 세팅되어있는 정보를 기반으로 cloud run에 자동 배포 (/main 브랜치 push 시 트리거 발동)

log level error를 넘어가면 slack으로 알림 발송

약관은 클라이언트와 미리 약속한 ID 또는 키워드로 약관 동의를 받도록 한다.
서버에서는 POST /members 시점에 필수약관들 모두 체크했는지만 검사하고, 따로 db에 저장하지 않아도 될 것 같다.

1. golang에서 워커 풀을 관리할 수 있는 방법.
2. #22 에서 언급했듯, 서버리스 prod환경에서는 stateless 해야한다. 즉 worker가 계속 동작할 수 없고, 트리거가 있어야 한다. 이를 해결하기 위해 아래 두가지 서비스 도입을 생각해본다.
   1. google cloud scheduler
   2. google cloud pubsub trigger
3. 클라앱과 통신하기 위해서는 ios / aos 간 interface가 필요하다. 이를 위해 두가지 전략중 하나를 선택해서 배포한다.
   1. firebase를 사용한 통합 interface 관리
   2. 각 os에 맞춘 통한 interface 개발
      1. Ios: APNs
      2. Aos: FCM(firebase) or GCM(google cloud)