이번 미션은 첫 협업 미션이었습니다. 프론트엔드 크루분들을 포함해 총 5명으로 구성된 팀으로 협업을 진행했습니다. 그 과정에서 얻었던 다양한 경험들을 기록하고자 합니다. 배포 및 인프라 협업 미션을 진행하면서, 백엔드는 기본적인 뼈대 코드를 제공받았습니다. 이 뼈대 코드를 통해 우선 배포 및 인프라 구성을 해보는 것이 첫번째 미션이었습니다. 그리고 이 과정에서 계정을 지급받아 AWS를 사용했습니다. 배포 플로우는 다음과 같았습니다. 정말 간단하게 구성했는데 이 과정에서 AWS 개념, 네트워크 개념, 그리고 다양한 리눅스 명령어들을 접해보게 되었습니다. 각각에 대해 모두 다루기엔 너무 방대해질 것 같아, 이들에 대해서는 아래에 따로 정리하겠습니다. AWS, EC2, VPC, AZ, Subnet? 각 개념에..
영속성이란? 영속성이란 데이터를 생성한 프로그램의 실행이 종료되더라도 사라지지 않는 데이터의 특성을 의미합니다. 우리가 일반적으로 코드 레벨에서 다루는 객체는 이런 영속성을 가지지 않습니다. 객체는 메모리 상에서만 존재하며 어플리케이션이 종료되면 사라집니다. 우리가 만든 객체들에게 영속성이라는 특성을 부여하려면 어떻게 해야할까요? 쉽게 말해, 객체를 어떻게 영구하게 저장할 수 있을까요? 이런 고민을 해결해주는게 JDBC, SQL Mapper, ORM입니다. 그리고 각각은 다른 특성을 가지고 있습니다. 이번에는 세 가지 기술에 대해 정리해보고자 합니다. JDBC 가장 먼저 살펴볼 영속화 기술은 JDBC입니다. JDBC(Java DataBase Connectivity)는 자바에서 데이터베이스에 접속할 수 있..
이전 포스팅에서는 REST란 무엇인지를 살펴보았습니다. REST는 총 6개의 제약조건을 가지고 있었죠. https://dev-ws.tistory.com/72 REST 기본 개념 총정리 2편 - REST의 6가지 제약조건 소개 이번에는 REST란 무엇인지를 알아보겠습니다. 1편인 REST의 등장 배경은 아래 링크를 참고해주세요! https://dev-ws.tistory.com/71 REST 기본 개념 총정리 1편 - REST의 등장 배경 이번에 RESTful API를 주제로 테 dev-ws.tistory.com 그런데 균일한 인터페이스 제약조건의 경우 만족하기가 매우 어렵다고 했습니다. 이번 포스팅에서는 왜 그렇게 어려운지, 어떤 개념을 내포하고 있는지 살펴보도록 하겠습니다. 균일한 인터페이스 균일한 인터..
이번에는 REST란 무엇인지를 알아보겠습니다. 1편인 REST의 등장 배경은 아래 링크를 참고해주세요! https://dev-ws.tistory.com/71 REST 기본 개념 총정리 1편 - REST의 등장 배경 이번에 RESTful API를 주제로 테코톡 발표를 진행하게 되었고, 발표를 준비하면서 학습했던 자료들을 토대로 REST의 기본 개념을 정리하고자 합니다. 대부분의 내용은 로이 필딩의 논문에서 비롯되 dev-ws.tistory.com 이전 편에서 언급했던 것처럼, 기존 WWW에는 몇가지 문제점들이 존재했습니다. 그리고 이런 문제를 해결하기 위해서 로이 필딩은 REST라는 개념을 제시했는데요. 그렇다면 REST는 무엇일까요? 정말 쉽게 정리하면 'WWW을 위한 제약조건의 집합'이라고 이해해도 될..
이번에 RESTful API를 주제로 테코톡 발표를 진행하게 되었고, 발표를 준비하면서 학습했던 자료들을 토대로 REST의 기본 개념을 정리하고자 합니다. 대부분의 내용은 로이 필딩의 논문에서 비롯되었으나, 설명을 위해 주관적인 내용이 포함될 수도 있다는 점은 미리 알려드리고자 합니다. REST가 없던 시기, 무엇이 문제였나 REST를 이해하기 앞서, 이전에는 도대체 무엇이 문제였길래 REST라는 개념이 등장했는지를 먼저 살펴봅시다. 1990년대 초반에 WWW(World Wide Web)은 폭발적으로 사용되기 시작했습니다. 그리고 이를 통해서 사람들은 정보의 공유와 접근을 굉장히 쉽게 할 수 있었습니다. WWW은 단순성과 접근성이 아주 좋았기 때문입니다. 누구나 정보에 접근하고 싶다면 컴퓨터 하나를 들고..
컨트롤러 - 서비스 DTO 분리 이번 미션에는 컨트롤러와 서비스 간의 통신에 있어 DTO를 사용했습니다. '컨트롤러와 서비스 간에 무엇을 주고받을것인지'는 오랜 관심사이기도 했는데요. 1. 도메인 객체를 주고받는 방법, 2. 표현 계층의 DTO를 주고받는 방법 모두 시도해봤기에 이번엔 조금 다른 방법을 시도해봤습니다. 바로 서비스 전용 DTO를 생성하는 것입니다. 물론 실무에서 적용할 수 있을지에 대해서는 확신이 들지는 않지만 연습 과정에 있어서는 큰 도움이 될 것 같았기 때문입니다. 구조는 다음과 같습니다. public void enrollStation(@Valid EnrollStationCommand command) { Line line = lineRepository.findById(command.g..
CRUD와 도메인 엔티티 이번 지하철 미션에서는 Line이라는 도메인 엔티티가 존재했습니다. 이 Line이라는 도메인 엔티티는 '노선'이라는 개념을 담습니다. 그리고 기본적으로 제공된 Line 객체는 다음과 같았는데요. public class Line { private Long id; private String name; private String color; ... } 이후 저는 '노선은 어느 역이 포함되어 있는지 알고 있어야 한다'는 요구사항에 따라 다음과 같이 sections라는 프로퍼티까지 추가했습니다. public class Line { private final Long id; private final String name; private final String color; private fin..
Proxy의 역할 proxy란, '대리'라는 뜻입니다. 그리고 이 용어는 IT 분야 곳곳에서 다양하게 사용됩니다. 예를 들어 Proxy pattern, Spring proxy, Network proxy 등이 있는데요, 이번 아티클에서 살펴보고자 하는 부분은 Network proxy입니다. 개발자의 길을 걷다보면 많은 부분에서 공통적으로 접하게 되는 개념이 있습니다. 바로 추상화입니다. 추상화란, 불필요한 차이점을 배제하고 공통점만을 추출하는 작업을 의미합니다. 이런 추상화가 왜 중요할까요? 복잡도를 획기적으로 낮춰주기 때문입니다. 제가 추상화에 대한 이야기를 한 이유는 Network Proxy도 하나의 추상화 메커니즘이기 때문입니다. 그럼 어떤 것을 추상화하느냐? 바로 네트워크 통신 자체를 추상화합니다...
Web Server란? 웹 서버는 1. 하드웨어 웹 서버, 2. 소프트웨어 웹 서버로 분류됩니다. 하드웨어 웹 서버의 경우는 웹 서버가 설치되어 있는 컴퓨터를 의미하며 소프트웨어 웹 서버의 경우 클라이언트로부터 HTTP 요청을 받아 정적 컨텐츠(html, css, png 등)를 제공하는 프로그램을 의미합니다. 그리고 대표적인 소프트웨어 웹서버로는 Apache, Nginx가 있습니다. 웹 서버는 정적 컨텐츠를 전달한다고 했는데요, 이처럼 웹 서버의 주된 목적은 웹 페이지, 이미지 파일 등을 클라이언트로 전달하는 것입니다. 그렇다면 동적 컨텐츠에 대한 HTTP 요청이 들어왔을 때의 처리는 누가 해주는걸까요? 바로 WAS입니다. WAS(Web Applicaition Server) WAS는 DB 조회나 다양한..
스프링과 데이터베이스 개념을 처음 접하고나서부터 가장 큰 고민은 '도메인 엔티티에 ID를 부여하는 기준은 무엇인가?' 이었습니다. 그리고 레벨 2를 마쳐가는 지금, 어느정도 저만의 생각이 확립된 것 같아 기록의 목적으로 아티클을 작성해두고자 합니다. 추후에 '이때는 이런 생각을 했었구나!' 라는 생각이 들 수 있도록이요. 따라서 아래 내용은 주관적인 생각이 대부분입니다. ID의 필요성영속성 개념을 접하게되면 겪는 가장 큰 문제점은 객체지향과 영속화 사이의 괴리감(패러다임의 불일치)입니다. 분명 객체지향적으로 짜야 하는데, 데이터 중심 설계를 하게 되는 경우도 많고 도메인 엔티티와 영속성 엔티티를 분리하기가 어려운 등... 여러 문제들이 발생합니다. 그리고 이런 괴리감이 드는 이유 중 하나가 도메인 엔티티..
