HTML 삽입 미리보기할 수 없는 소스 #0. 개요 아마존 ec2 서비스로 서버를 실제로 만들어 서버를 구축하고 싶은데, 매번 할 때마다 조금씩 찾아봐야 했어서 졸업프로젝트를 진행하는 과정에서 겪었던 문제와 함께 서버 구축 과정을 정리하였다. 커맨드 위주 #1. 초기 세팅 1. 아마존 ec2 인스턴스 시작 https://codemonkyu.tistory.com/entry/AWSEC2-인스턴스-생성하기-12 우분투 선택 키페어 챙기기 보안그룹설정 탄력적 ip 설정 https://velog.io/@mintmin0320/AWS-EC2를-활용한-Nest.js-서버-배포 인바운드 규칙 포트번호 유의! 💡 진입 명령어: (window: cmd 창) ssh -i "키페어 이름.pem" ubuntu@ec2-ip.ip...

HTML 삽입 미리보기할 수 없는 소스 #0. 개요 controller에서 put / post method API 를 swagger 에 작성할 때, 스키마 뿐만 아니라, ExampleObject 코드로도 request body 가 어떤 모양이어야 하는 지 프론트엔드에게 설명을 해주고 싶다. 원할한 프론트 - 백 소통을 위해 그러나, controller의 코드가 swagger example value 문자열 때문에 너무 길어져서 백엔드 코드 가독성이 떨어졌다 심지어 exampleObject가 controller 마다 여러개 일 수도 있고, request Body Dto Class가 property 가 많으면 종잡을 수가 없다. @PostMapping("/item") @Operation(description..

HTML 삽입 미리보기할 수 없는 소스 #0. 개요 원활한 프론트 - 백 소통을 위해, 개발하는 동시에 API 명세서를 만들어주는 swagger를 작성하는데에 소홀히하면 안 된다. 백엔드 개발자는 코드를 직접 구현하여서, 스웨거를 통해 API 가 잘 호출되고, 결과가 이상적으로 리턴만 되는 것을 보면 스웨거도 잘 구현이 되었다고 생각을 하지만, 코드를 보지 못 하는 프론트엔드 개발자 입장에서는 각 API의 response / request 가 어떤 모양인지, 또한 각 Dto의 property 가 값의 유효 범위가 어떻게 되는지, 의미하는 바가 뭔지 알 수 있길 원한다. 그렇기에 스웨거가 제공해주는 여러 어노테이션을 활용해 스웨거 문서를 직관적으로 꾸며보자 #1. 어노테이션 종류 1. @Operation ..

#1. 회계(accounting) 기본 분석 1. 전표(Voucher) https://blog.naver.com/robot179/220758971019 위 블로그처럼 전표메인과 전표상세를 담는 테이블로 나뉘어야함 전표메인 전표상세의 집합 하나의 전표안에 해당 전표를 나타내는 값들과 여러 계정과목 차대 내역을 가지고 있음. 계정과목 내역은 전표상세 테이블로 미루고, 나머지 값들을 전표메인 테이블로 전표상세 계정과목 값들을 넣는 행을 담는 테이블 전표관리항목 전표상세에서 계정과목 값들 중, 계정과목 세팅에서 관리항목을 가지고 있는 값들에 대해 관리항목 값을 담는 테이블 계정과목의 관리항목 세팅에 따라 전표상세 행 하나당 전표관리항목 행이 안 생길 수도, 하나 생길 수도, 두 개 이상 생길 수도 있음. 2. ..

#1. 개요 API를 구현할 때 기획과 프론트엔드의 요구로 인해 기존 Dto에 property 가 하나씩 추가되어야할 때가 있다. 호출되는 데이터의 DB 스키마가 변경되지 않더라도 말이다! 처음에 기존 Dto에 계속 property 를 추가했더니 하나의 Dto가 너무 커지고, 여러 API에 쓰이기 시작했다. 결과적으로 스웨거에 스키마가 올라갔을 때, 각 API에서 안 쓰이는 property 가 많아졌다. 이는 백엔드, 프론트엔드 양쪽에 다 여간 불편한 것이 아니었다. 그렇기에 Dto를 여러 개로 나누려했다. 그러나 나누려하는 이 Dto들은 결국 비슷한 정보를 리턴하기에, 겹치는 정보가 많았다. 그렇기에 아예 분리를 하기보다, 상속을 하는 것이 제일 좋은 판단이라고 생각했다. 그리고 분류를 해보면 보통 같..

HTML 삽입 미리보기할 수 없는 소스 #1. 설명 UML Diagram(시퀀스다이어그램) 특정 행동이 어떤 순서로 어떤 객체와 어떻게 상호작용하는 지 표현하는 행위 다이어그램 사용자 / 프론트 / 백 세개의 객체로 구분하고, 기획 / 프론트엔드 / 백엔드 개발 간 상호 소통을 원활히 될 수 있도록 도울 수 있음 기획자: 사용자 ↔ 서비스간 상호 작용을 고려 프론트엔드: 사용자에게 요청이 들어오면 어떤 API를 호출해, 어떤 데이터를 백엔드로부터 받아와서 어떻게 사용자에게 뿌려줄 지 고려 백엔드: 프론트엔드 측에서 어떤 데이터를 통해 요청을 하여 어떤 데이터를 요구할 지 고민해서 어떤 API를 구현할 지 고민 이 세 개의 고민을 해소해주기 위해 세 객체 사이의 상호 작용을 시퀀스 다이어그램을 통해서 도식..