Software Architecture

• 1: Frontend Error Handling
• 2: Frontend Authentication
• 3: Config Management

1 - Frontend Error Handling

Error 구분에 따른 처리 (API)

• NotFoundError : 리소스를 찾을 수 없을 때 (status: 404)

• BadRequestError : 잘못된 요청을 보낼 때 (status: 400)

• AuthenticationError: 인증이 실패했을 때 (status: 401)

• AuthorizationError: 권한 검증에 실패했을 때 (status: 403)

• APIError: 이외의 모든 API Error 및 서버 에러 (status: 500 등)

이 에러들을 axios api client의 interceptor에서 받아 핸들링한다. 위에 명시된 에러 이외에 다른 에러 코드를 정의할 수도 있다.

axios의 interceptor에서 error가 왔을 때, 각 statusCode를 보고 판별하여 위에 미리 정의해둔 Error로 throw해준다.

Error Handler (Client)

AuthenticationError의 경우

Token이 유효한 지 확인하고, 유효하지 않을 경우 Authentication Error Handler를 호출하여 에러를 처리한다.

Authentication Error Handler는 다음과 같은 동작을 한다.

• Session 만료 모달을 보여줌

• User의 Session을 만료시킴

AuthorizationError의 경우

Authorization Error Handler를 호출한다. 이 핸들러는 다음과 같은 동작을 한다.

상단에 권한이 없다는 경고창을 노출시킴

NoResourceError의 경우

No Resource라는 토스트를 보여주고, redirect url이 있을 시 해당 url로 이동시킨다.

APIError의 경우

콘솔창에 API Error라고 명시된 로그를 남긴다.

BadRequestError의 경우

페이지에서 넘겨준 Error Message가 적힌 toast 경고창을 띄운다.

Error를 추가하는 방법

1. SpaceConnector(console-core-lib > space-connector/error.ts)에 새로운 에러를 정의한다.

2. SpaceConnector의 Error Interceptor(console-core-lib > space-connector/api.ts)에 새로운 에러를 throw해주는 부분을 추가해준다.

3. API의 error가 아니라 Client 자체에서 필요한 에러의 경우 Client(console > common/error.ts)에 새로운 에러를 정의하고, 에러가 발생할 시 해당 에러를 throw한다.

4. Error Handler(console > common/composables/error/errorHandler.ts)에 새롭게 추가된 Error를 핸들링하는 코드를 추가한다.

Error를 사용하는 방법

에러 클래스를 작성하고, 그 에러 클래스를 이용해 만든 에러 핸들러를 실제 프로젝트에서는 아래와 같이 사용한다.

• list 등 일반적인 작업

try {
    특정 동작
} catch (e) {
    ErrorHandler.handleError(e);
}

• create/update 등 실패 시 toast message를 보여주어야 하는 작업
  

try {
    특정 동작
} catch (e) {
    ErrorHandler.handleRequestError(e, 번역을 위한 i18n key값 or string);
}

2 - Frontend Authentication

인증 플로우

Authenticator

abstract class Authenticator {
	static async signIn(필요한 매개변수): Promise<void> {
    	// sign in 로직
    }

    static async signOut(): Promise<void> {
    	// sign out 로직
    }
}

export {
	Authenticator,
}

signIn을 위해 백엔드 인증 서버에 보낼 credentials라는 데이터가 필수적이고, userId와 userType(일반 User인지, 관리자인지, API만 사용하는 API user인지)을 부수적으로 받습니다. signOut에서는 vuex에 작성해놓은 signOut 메서드를 호출합니다.

커스텀 인증 클래스

// custom-auth.ts

class CustomAuth extends Authenticator {
    const signIn = async () => {
        // 각 SSO, 커스텀 인증에 필요한 Sign in 로직
        const credentials = { // 각 커스텀 인증에서 생성된 credentials }
        super.signIn(credentials);
    }

    const signOut = async () => {
        // 각 SSO, 커스텀 인증에 필요한 Sign Out 로직
        super.signOut();
    }
}

결론적으로, 커스텀 Auth class 내부에 상속받은 Authenticator(=super)의 함수들을 호출하여 SpaceONE의 인증을 동시에 수행할 수 있도록 합니다.

커스텀 인증 클래스 loader

export const loadAuth = (authType?) => {
    if (authType === 'CUSTOM_AUTH') return CustomAuth;
    return SpaceAuth;
};

SignIn은 개별 템플릿을 가지지만, SignOut은 어디에서든 호출될 수 있기 때문에 위와 같은 loader를 사용하여 현재 도메인의 인증 타입을 넣으면 알맞은 인증 로직을 수행할 수 있도록 작성합니다.

커스텀 인증 템플릿

//Custom Auth의 template(external/custom/template/CUSTOM_AUTH.vue)

<template>
	<div>Custom 로그인을 위한 폼 버튼</div>
</template>

<script lang="ts">
 setup() {
 	//필요한 로직들
 	onMounted(async() => {
    		try {
            	await loadAuth('CUSTOM_AUTH').signIn(); //loader를 사용하여 customAuth 클래스의 signIn 함수 호출
            } catch (e) {
            	//에러 핸들링
            }
        }
    )
 }
</script>

//sign-in page
<component :is="component" class="sign-in-template"
	@sign-in="handleSignIn"
/>

//sign-in page
  const state = reactive({
  	...
	component: computed(() => {
                let component;
                const auth = state.authType;
                if (auth) {
                    try {
                        component = () => import(`./external/${auth}/template/${auth}.vue`);
                    } catch (e) {
                        //필요한 에러 핸들링.
                    }
                }
                return component;
            }),
  })

3 - Config Management

App에 필요한 구성 요소를 정의한다. 주로, 환경 별로 다른 값을 다룬다.

환경 별 우선순위

default.json이 우선적으로 적용된다.

development 환경일 경우, development.json의 값이 덮어 쓰여 적용된다.

환경 설정 방법

Dockerfile 수정

Dockerfile에서 npm run build 커맨드 전 NODE_ENV로 환경 설정 가능

...
ENV NODE_ENV development
...

Webstorm Configurations 수정

Run/Debug Configuration 설정 시 Environment 필드값 수정

Default Config 정보

• development.json 권장 예시

  {
      "VUE_APP_API": {
        "ENDPOINT": "https://sample.com"
      },
      "GTAG_ID": "DISABLED",
      "DOMAIN_NAME": "sample",
      "DOMAIN_NAME_REF": "config",
      "ASSETS_ENDPOINT": "https://sample-asset.com/assets/"
  }
  

Config 파일 위치

• Default: <SOURCE_ROOT>/public/config/default.json
• Each Environment: <SOURCE_ROOT>/public/config/<NODE_ENV>.json

Config 사용 방법

import config from '@/lib/config'

config.get(); // All Values
config.get('VUE_APP_API.ENDPOINT'); // Value of specific key