- Game API 서버로써, ASP.NET Core 8로 제작되었습니다.
- Redis의 SETNX 기능을 사용하여, 유저당 하나의 요청만 처리하도록 구현하였습니다.
- SETNX 코드
| 종류 | 라이브러리 |
|---|---|
| Framework | ASP.NET Core 8 |
| Database | MySqlConnector, SqlKata |
| Redis | CloudStructures |
| Logger | ZLogger |
| 기능 | 완료 여부 |
|---|---|
| 로그인 체크 | 완료 |
| 유저 로그인 | 완료 |
| 게임 데이터 로드 | 완료 |
| 유저 로그 아웃 | |
| 매칭 기능 | 완료 |
| 기능 | 완료 여부 |
|---|---|
| 메일 전송 | 완료 |
| 메일 전체 읽기 | 완료 |
| 메일 삭제 | |
| 메일 아이템 기능 | |
| 메일 수령 |
| 기능 | 완료 여부 |
|---|---|
| 출석 체크 | 완료 |
| 출석 체크 후 메일 전송 | 완료 |
| 출석 정보 조회 | 완료 |
- Middleware를 통해, 해당 유저가 로그인한 유저인지를 체크하는 기능을 구현.
- 로그인을 하게 되면 해당 유저의 ID를 Key로, 발급된 Token을 Value로 레디스에 저장함.
- 로그인 요청을 제외한 요청들에 한해서 요청 헤더에 있는 ID와 Token을, 레디스에 저장된 정보를 비교하여 인증 구현.
- 스마일게이트 리캠프에서 만든 유저 서버와 비교한 내용
- 리캠프에서는 완전 기초를 공부하기 위해 Databaes, Logger등을 직접 구현하였기 때문에 비교 X
-
서버 캠퍼스
- 하나의 컨트롤러가 하나의 요청을 담당하도록 함.
- 로그인, 로그아웃 등을 각각 하나의 컨트롤러로 구현
-
리캠프
- 하나의 기능에 대한 요청들을 하나의 컨트롤러가 담당하도록 함
- 로그인, 로그아웃, 회원가입 등을 하나의 컨트롤러로 구현
-
두 가지 방식 모두 장단점을 가진다고 생각함.
- 캠퍼스의 경우, 하나의 컨트롤러에 하나의 요청만 처리하기 때문에 컨트롤러의 코드가 길어지지 않아 유지보수에 좋다고 생각함.
- 다만, 요청이 많아질 수록 파일의 갯수가 많아진다는 단점이 존재.
- 리캠프의 경우, 반대로 컨트롤러 코드의 유지보수에는 불리할 수 있으나, 기능별로 컨트롤러가 존재하기 때문에 분리되어 있다는 것이 좋다고 생각됨.
-
서버 캠퍼스
- 에러가 발생하는 지점에서 바로 바로 에러 처리를 진행
-
리캠프
- 에러를 하나로 처리하기 위해 에러 발생하는 지점에서 Exception을 던지도록 함.
- 이를 Exception Middleware에서 받아서 처리하도록 구현함.
- 단점 : Exception이 발생하는 과정에서 생기는 오버헤드.
- 장점 : 한번에 모아서 에러를 처리할 수 있다.
-
서버 캠퍼스
- Controller에서만 로그를 기록, 이 외에는 에러가 발생할 때 마다 기록
-
리캠프
- AOP 라이브러리인
Castle.Core를 통해 Controller - Service - Repository 을 들어갈 때 마다 로그를 기록
- AOP 라이브러리인
- 항상 공부하면서 맞게 개발하고 있는지 궁금한 부분이 많았었는데, 궁금증을 해결할 수 있었음.
- 혼자서 공부했을 때 사용했던 방법이랑 다른 부분도 많았었지만, 맞는 부분도 있었음.
- 서버캠퍼스에서 배운 내용들을 잘 소화한다면 더욱 좋은 API 서버를 개발할 수 있을 것.
