원문 : How I write HTTP services after eight years. ( https://pace.dev/blog/2018/05/09/how-I-write-http-services-after-eight-years.html )
관련 동영상 : GopherCon 2019: Mat Ryer - How I Write HTTP Web Services after Eight Years
전체 내용은 원문에서 확인하실 수 있으며, 또 내용 중 일부 오역이 포함되어 있을 수 있으니, 가능하면 원문을 참조하시는 걸 추천드립니다.
서비스를 만드는 방법은 시간이 지남에 따라 바뀌어왔습니다. 그래서 지금은 서비스를 어떻게 만들고 있는지 각각의 경우에 따라 유용한 패턴을 예로 들어 공유하고 싶습니다.
서버 구조체.
서버 구조체는 서비스를 대표하는 객체입니다. 그리고 모든 곳에 의존성을 가지고 있습니다. 모든 컴포넌트는 다음과 같은 한 개의 서버 구조체를 가지고 있습니다.
type server struct {
db *someDatabase
router *someRouter
email EmailSender
}
• 구조체의 모든 필드를 통해 의존성을 공유합니다.
routes.go
모든 라우팅이 담겨있는 routes.go 파일을 모든 컴포넌트 안에 단일 파일로 가지고 있습니다.
package app
func (s *server) routes() {
s.router.HandleFunc("/api/", s.handleAPI())
s.router.HandleFunc("/about", s.handleAbout())
s.router.HandleFunc("/", s.handleIndex())
}
대부분의 코드 유지보수가 URL과 에러 리포트에서 시작하기 때문에 편리합니다. 그래서 routes.go를 한번 쓱 보면, 바로 어디를 봐야 하는지 알 수 있습니다.
서버와 분리된 핸들러.
HTTP 핸들러는 서버와 분리되어 있습니다.
func (s *server) handleSomething() http.HandlerFunc { ... }
핸들러는 서버 변수를 통해서 의존성에 접근할 수 있습니다.
핸들러의 반환
핸들러 함수는 모든 요청을 처리하지 않습니다. 단지 함수를 리턴합니다. 이것은 핸들러가 독립된 환경에서 동작하도록 해 줍니다.
func (s *server) handleSomething() http.HandlerFunc {
thing := prepareThing()
return func(w http.ResponseWriter, r *http.Request) {
// use thing
}
}
prepareThing()은 한번만 호출됩니다. 그래서 핸들러가 초가화 될 때마다 한 번만 만들고 사용할 수 있습니다. 이렇게 공유되는 데이터는 읽기만 가능하다는 걸 알아두세요. 만약 뭔가를 수정해야 한다면, mutex나 데이터를 보호할 뭔가가 있어야 합니다.
핸들러의 특정 의존성을 위한 인자 받기.
특정 핸들러만 의존성을 갖는다면, 인자로 받습니다.
func (s *server) handleGreeting(format string) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, format, "World")
}
}
format 변수는 핸들러에서 사용할 수 있습니다.
핸들러 대신 핸들러 함수를 사용.
저는 최근에 대부분의 경우에 http.Handler를 사용하기 보다는, http.HandlerFunc를 사용합니다.
func (s *server) handleSomething() http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
...
}
}
둘 다 사용 가능합니다. 그러므로 읽기 쉬운 것을 고르세요. 저는 http.HandlerFunc를 골랐습니다.
미들웨어는 Go 함수입니다.
미들웨어 함수는 http.HandlerFunc를 가져와서 원래 핸들러를 호출하기 전과 후에 코드를 실행할 수 있는 새로운 함수를 리턴하거나 원래 핸들러를 호출하지 않기로 결정할 수 있습니다.
func (s *server) adminOnly(h http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
if !currentUser(r).IsAdmin {
http.NotFound(w, r)
return
}
h(w, r)
}
}
핸들러 안의 로직은 원래 핸들러를 호출할지 여부를 선택적으로 결정할 수 있습니다. 위의 예제에서 관리자가 아니라면, 핸들러는 404 Not Found를 리턴합니다. h 핸들러는 호출되지 않습니다.
만약 관리자라면, h 핸들러를 실행합니다.
저는 항상 미들웨어 목록을 routes.go에 기록합니다.
package app
func (s *server) routes() {
s.router.HandleFunc("/api/", s.handleAPI())
s.router.HandleFunc("/about", s.handleAbout())
s.router.HandleFunc("/", s.handleIndex())
s.router.HandleFunc("/admin", s.adminOnly(s.handleAdminIndex()))
}
요청과 응답 유형도 함수에 들어갈 수 있습니다.
엔드포인트가 자체 요청 및 응답 유형이 있는 경우 일반적으로 해당 특정 핸들러에만 유용합니다.
이런 경우라면, 함수안에 정의할 수 있습니다.
func (s *server) handleSomething() http.HandlerFunc {
type request struct {
Name string
}
type response struct {
Greeting string `json:"greeting"`
}
return func(w http.ResponseWriter, r *http.Request) {
...
}
}
이렇게 하면 패키지 공간을 정리하고 핸들러 버전을 고려할 필요 없이 이러한 종류의 이름을 동일하게 지정할 수 있습니다.
테스트 코드에서 유형 코드를 테스트 펑션으로 복사하여 동일하게 만듭니다. 또는..
테스트 유형은 테스트하는데 도움이 됩니다.
요청과 응답 유형이 핸들러 안에 숨겨져 있다면, 테스트 코드에서는 새로운 유형을 선언할 수 있습니다. 이것은 이 코드를 후에 읽을 누군가를 위해 이야기하는 기회입니다. 예를 들어 Persion 유형이 있고, 여러 엔드포인트에서 사용하고 있다고 가정하겠습니다. 만약 greet 엔드포인트가 있고, 여기서는 이름만 관심이 있을 수도 있기 때문에 아래처럼 테스트 코드로 표현할 수 있습니다.
func TestGreet(t *testing.T) {
is := is.New(t)
p := struct {
Name string `json:"name"`
}{
Name: "Mat Ryer",
}
var buf bytes.Buffer
err := json.NewEncoder(&buf).Encode(p)
is.NoErr(err) // json.NewEncoder
req, err := http.NewRequest(http.MethodPost, "/greet", &buf)
is.NoErr(err)
//... more test code here
이 테스트를 통해서 명확해 졌습니다. Person의 이름이 우리가 관심을 가지는 유일한 필드임을 말입니다.
의존성 설정을 위해 sync.Once 사용
핸들러를 시작할 때, 조금이라도 오래걸린다면, 저라면 핸들러가 처음 불려질 때까지 미룰 것입니다. 이렇게 하면, 애플리케이션의 시작하는 시간을 줄여줍니다.
func (s *server) handleTemplate(files string...) http.HandlerFunc {
var (
init sync.Once
tpl *template.Template
tplerr error
)
return func(w http.ResponseWriter, r *http.Request) {
init.Do(func(){
tpl, tplerr = template.ParseFiles(files...)
})
if tplerr != nil {
http.Error(w, tplerr.Error(), http.StatusInternalServerError)
return
}
// use tpl
}
}
sync.Once는 코드가 한번만 수행되도록 해줍니다. 그리고 다른 요청(다른 사람에 의한 동일한 요청)은 실행이 끝날 때까지 막아줍니다.
• 오류 검사는 초기화 함수 외부에 있으므로, 만약 뭔가 잘못된다해도, 에러를 접할 수 있고, 로그도 유실되지 않습니다.
• 핸들러가 호출되지 않으면, 시간이 많이 드는 작업은 결코 실행되지 않습니다. 이건 코드가 어떻게 배포되느냐에 따라서 아주 큰 이득이 될 수 있습니다.
이걸 꼭 기억하세요. 초기화를 시작할 때에서 실행할 때(첫번째로 호출되었을 때)로 이동하는 것입니다. 저는 Google App Engine을 주로 사용하는데, 그래서 이러한 것이 저에겐 적합합니다. 하지만 이런 방식으로 sync.Once를 사용하는 것이 상황에 따라 다를 수 있으므로 언제, 어디서 사용하느냐를 생각해볼 필요가 있습니다.
서버는 테스트할 수 있습니다.
우리의 서버 유형은 테스트를 할 수 있습니다.
func TestHandleAbout(t *testing.T) {
is := is.New(t)
srv := server{
db: mockDatabase,
email: mockEmailSender,
}
srv.routes()
req := httptest.NewRequest("GET", "/about", nil)
w := httptest.NewRecorder()
srv.ServeHTTP(w, req)
is.Equal(w.StatusCode, http.StatusOK)
}
• 각 테스트에서 서버 인스턴스를 생성합니다. 만약 시간이 많이드는 것을 나중에 로딩되도록 한다면, 커다란 컴포넌트를 사용하더라도 시간이 많이 걸리지 않을 것입니다.
• serveHTTP를 호출함으로써, routing을 포함하여, middleware 등 모든 스택을 테스트합니다. 이렇게 하지 않으려면 각 핸들러 메서드를 호출해도 됩니다.
• 핸들러가 뭘 하는지 기록하기 위해서 httptest.NewReqeust와 httptest.NewRecoreder 를 사용하세요.
• 이 코드 샘플은 경량의 테스트 프레임웍 is( https://github.com/matryer/is ) 를 사용합니다. ( Testify의 대체품 )