Nuxt × Go × AWS 로 비교 커뮤니케이션적인 게시판 서비스 만들어 보았다

비교 커뮤니케이션 사이트 Versus
htps : // ゔぇr す s ぇ b. 네 t (정지 중)





Twitter에서 기술 마운트 전투를하는 사람들이 재미있었습니다.
AWS와 Go를 공부하고 테마를 들고 커뮤니케이션할 수 있는 간단한 게시판 사이트를 만들어 보았으므로 작업공정 등을 기록해본다.

구성

인프라

ECS

Lambda

DynamoDB

API 게이트웨이

Route 53

백엔드

Go

프런트 엔드

Nuxt (SSR)

Go와 Fargate 근처를 사용하고 싶었기 때문에 이런 구성이 되었습니다.

작업공정

작업 관리

작업 관리 도구로 Trello를 사용했습니다.

이런 느낌으로 5컬럼으로 관리해 보았다.
Doc로서 문서 관리에도 사용해 보았지만, 심플하고 바삭하게 움직이고, 개인 개발 규모라면 몹시 사용하기 쉽다고 생각했다.

디자인

Figma 사용.

이런 식으로 천이도 만들거나

색 관리도 하면서, 확실히 확실히 사용해 본 생각(디자이너 분으로부터 하면 아직 아직일 것이다)
이 정도 해 두면 개발시 상당히 편하다.

개발

5

Lambda에서 채용. 디렉토리 구성은 다음과 같습니다.

.
├── posts-function
│   └── posts
│       ├── bin
│       ├── cmd
│       └── internal
│           ├── actions
│           ├── handler
│           ├── models
│           └── repositories
└── threads-function
    └── threads
        ├── bin
        ├── cmd
        └── internal
            ├── actions
            ├── handler
            ├── models
            └── repositories
                └── mock

AWS SAM을 사용하여 명령을 사용하여 Go의 Lambda 함수를 생성할 수 있습니다.
디렉토리 구성은 golang-standards을 참고로 했다.
어떤 입도로 Lambda 함수를 작성할지 헤매었지만, 자원 단위로 분할하기로 하고, 다음과 같이 핸들링해 보았다.

handler.go

package handler

import (
    "context"

    "posts/internal/actions"

    "github.com/aws/aws-lambda-go/events"
)

var routes = map[string]actions.ActionFactory{
    "GET":  actions.NewPostsGetter,
    "POST": actions.NewPostsPoster,
}

// CORS compatible
var headers = map[string]string{
    "Content-Type":                "application/json",
    "Access-Control-Allow-Origin": "*",
}

func Handler(ctx context.Context, request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    factory := routes[request.HTTPMethod]
    action := factory()
    jsonData, err := action.Run(request)
    if err != nil {
        return events.APIGatewayProxyResponse{}, err
    }

    return events.APIGatewayProxyResponse{
        Body:       string(jsonData),
        StatusCode: 200,
        Headers:    headers,
    }, nil
}

HTTP 메소드로 배분할 뿐이므로 라우팅은 편하다. 함수를 나누면 당연히 배포도 나눌 수 있으므로, 이 근처의 입도는 규모를 보면서 같은 느낌이 될 것 같다. (덧붙여서 다른 프로젝트에서는 마이크로서비스 입도로 나누고 있었다)

Nuxt

프런트 엔드에서 채용.
기본적으로 초기 표시 속도적인 의미로 SSR을 해야 한다고 생각하고 있으므로 이번에도 SSR을 채용.
어려운 일을하지 않기 때문에별로 특별한 점이 없지만
밸리데이션에 vuelidate 를 사용해 보고 매우 사용하기 쉬웠으므로 추천하고 싶다.
인기 VeeValidate와 비교하면 vuelidate는 템플릿과 응용 프로그램 논리가 분리되어 있으므로 유효성 검사 프로세스를 가늘게 설정하려는 요구 사항이있을 때 사용하기 쉽습니다.

소감

AWS와 Go가 거의 처음 보았기 때문에 상당히 고생했다.
Node라면 Lambda의 코드를 AWS Console에서 볼 수 있기 때문에 가볍기 쉽지만, Go의 경우 그것이 불가능하고 배포 주위를 정돈할 때까지 힘들었다.
새롭게 무언가를 만들 때는 미지의 기술은 1종류로 해야 할, 같은 이야기를 어딘가에 들었지만 그대로라고 생각했다.
그러나 이번 기술 스택은 상당히 귀로 하는 것도 많아져 왔기 때문에, 시험해 보는 것은 일흥이라고 생각한다.