백엔드13 Naive한 HTTP 요청/응답을 parsing 할 때 주의점 개요현대 소프티어 백엔드 1주차 과제로 spring을 쓰지 않고 tcp socket 연결을 통해 웹 서버를 구현하는 실습을 진행 중이다.이전에 KUIT 3주차 과제에서 진행했던 경험이 있고, '네트워크 프로그래밍'이라는 과목에서 java로 멀티 스레드, socket 통신을 구현한 바 있기에 크게 어렵진 않았다고 생각했다. 구현을 마치고 의기양양해 있었는데 1주차 피드백에서 대차게 까였다.까인 이유 중 하나는 HTTP 프로토콜에 대한 이해 부족이었다. HTTP/1.1과 HTTP/2, HTTP/3 의 차이를 잘 알고 있는가?method, http-version, Header에서 대소문자 구분을 허용하는가?OWS를 허용하는 부분은 어디까지인가?header에서 key와 콜론 사이에 공백은 허용하는가?유니코드로 .. 2025. 7. 13. 템플릿/콜백 패턴 이해하기 with JdbcTemplate (토비의 스프링 Chapter 3) 개요이전 포스팅에서 말했듯이 마크다운 파일에서 바로 업로드 하는거라 형식 오류가 있을 수 있다. 내용209p ~ 278p 템플릿이란변경이 거의 일어나지 않으며 일정한 패턴으로 유지되는 특성을 가진 부분을 자유롭게 변경되는 성질을 가진 부분으로부터 독립시켜주는 기능을 말한다. 계속 개선 해오던 UserDao 코드를 통해 템플릿을 소개한다. 3.1 다시 보는 초난감 DAO3.1.1 예외처리 기능을 갖춘 DAO 기존 UserDao도 많은 부분이 개선되었지만 예외 상황에 대한 처리가 아쉬웠다.특히나 deleteAll() 이라는 메서드를 보면 예외처리가 전혀 안되어 있음을 확인 할 수 있다. public void deleteAll() throws SQLExcpetion{ Connection c = data.. 2025. 5. 10. Spring Test 동작원리 이해하기 (토비의 스프링 Chapter 2) 개요이전 포스팅에서 말했듯이 마크다운 파일에서 바로 업로드 하는거라 형식 오류가 있을 수 있다.내용145p ~ 207p 토비는 스프링이 개발자에게 제공하는 가장 중요한 가치는 객체지향과 테스트 라고 한다.1장에서 객체지향 좀 배웠으니까 2장에선 테스트에 대해서 살펴본다. 스프링으로 개발하면서 테스트를 만들지 않는 것은 스프링의 가치를 절반 포기하는 것이라고 한다.😱 스프링에서의 테스트는 작은 단위의 테스트가 가능하도록 해준다. --> 단위 테스트 초기에는 테스트 코드를 작성하는 것의 장점에 대해서 줄줄 설명한다. UserDaoTest 코드 개선여기서도 1장에서처럼 코드를 개선해나가며 테스트의 개념을 설명한다.1장에서 UserDao 클래스의 동작을 검증하기 위해 만들었던 UserDaoTest 라는 코드를.. 2025. 5. 10. IoC/DI를 이용한 객체지향 설계 (토비의 스프링 Chapter 1) 개요재연이 형이랑 주언이 형이랑 항상 하는 스터디에서 새로운 책을 공부하기로 했다. 처음엔 집콕 서버 리팩토링두 번째는 모던 자바 인 액션 책이번에는 토비의 스프링 책 공부다. 이미 chapter 3까지 공부했는데,그동안 나는 공부한 내용을 옵시디언 툴을 사용해서 마크다운 파일로 정리하고, 이를 깃헙에 WIL 레포에 올렸다. 근데 이렇게만 하니 뭔가 허전해서 블로그에도 포스팅을 하려고 한다.사실 블로그 포스팅할게 없어서 이걸로 때우는... 그리고 책 공부 포스팅은 아마 마크다운으로 정리한 걸 그대로 올리는 식으로 쓸 예정이라글 형식이 이쁘지 않을 것 같긴하다. 내용 53p ~ 144p스프링은 자바의 객체지향 프로그래밍을 지향하는 프레임워크 (강제는 x)오브젝트의 관리를 적극적으로 도와준다.[!note].. 2025. 5. 10. [백엔드] 도메인 간 의존성을 완전 분리시킬 수 있나? 개요집콕 프로젝트 쿼리 최적화를 했던 스터디를 계속 진행중이다. 집콕 프로젝트 쿼리 개선이 만족할만한 결과를 내었다고 판단해서 현재는 '모던 자바 인 액션' 이라는 책을 통해 자바 8,9,10 개념을 공부 중이다. 스터디에서는 책에 대한 내용 뿐만 아니라 각자 공부, 프로젝트 활동하면서 겪었던 이슈들을 공유하곤 하는데,어느날에 도메인 간 의존성 분리에 대한 내용이 나왔고, 당시에 토론한 것을 정리해보고자 한다. 상황상황은 다음과 같다. 전체 시스템을 여러 도메인으로 분리해서 다루고 싶었다.spring boot 프로젝트에서 패키지를 분리하고 각 패키지의 클래스 간 호출(의존성)을 없앤다. 그리고 DB에서도 도메인 간 연관관계를 다 끊는다. 즉, 각 도메인을 별도의 VM에 올려도 의존관계에서 전혀 문제가 .. 2025. 3. 30. [ToHero 백엔드 개발일지] NGINX로 웹 프론트, WAS 요청 분리하기 && 웹 프론트 CICD 환경 구축하기 (근데 저장공간 관련 트러블 슈팅을 곁들인) 개요Tohero 서비스의 프론트는 웹이다. 그래서 서비스 배포를 할 때 정적 파일을 반환하는 웹 서버가 필요했다. 서비스를 한창 개발할 때는, 편의를 위해서 프론트 배포, 백엔드 배포 환경을 따로 해서 각자 진행했었다. 서비스를 배포할 때가 되어서 어떤 식으로 배포를 진행할지 고민을 하다가 2가지 방법을 떠올렸다. 도메인 주소를 하나 더 사서 기존 프론트 배포 서버(WAS랑은 분리된)를 Record로 등록하기현재 WAS가 연결된 도메인 주소에서 NGINX로 요청에 따른 응답 분리하기 현재 DNS 주소가 https://tohero.co.kr 인데 (.com 이름은 이미 누가 사용중이었다...) 새로운 DNS 주소를 또 사는 건 비용적으로나 개발적으로나 안 좋은 것 같아서 하나의 서버로 합치기로 결정했다... 2025. 3. 10. 이전 1 2 3 다음
