BackEnd

지금까지는 웹 서버를 만들면서 서버 사이드 렌더링 방식만 이용했고, REST API를 제대로 다뤄본 경험이 없었습니다.따라서 REST API와 리액트 또는 뷰를 이용하는 프로젝트를 계획하고 하던 중 다음과 같은 의문이 떠올랐습니다.'REST API는 stateless

스프링부트로 편하게 개발이 가능하다 보니 그 기반이 되는 기술인 서블릿(servlet) 등에 대해 잘 모르고 있었습니다.따라서 이번에 서블릿과 WAS에 대해 정리해보고 스프링에서의 구조를 살펴보겠습니다.먼저 웹 서버와 WAS의 차이를 살펴보겠습니다.초창기의 웹 서버는

AWS에 서비스를 배포하는 방법을 간단하게 정리해보겠습니다. 배포를 처음 경험해서 잊지 않기 위해 개념적으로 정리한 글이라, 보다 자세한 내용이 궁금하신 분들은 아래 글을 참고하시면 되겠습니다. https://choppadontbiteme.tistory.com

배포를 목표로 새로운 프로젝트를 진행하기 시작했습니다. 이전의 프로젝트들과 달리 실제 배포를 목표로 진행하는 프로젝트이므로, 로그인 기능부터 확실하게 구현하고자 합니다. 이 글에서는 본격적으로 개발하기에 앞서 고민한 점들을 정리해두겠습니다. 풀스택으로 개발하고 운영을

MySQL을 통해 DDL을 먼저 작성한 후 JPA에서 entity를 설계하던 중, JPA constraints와 validation의 차이를 모르고 있다는 것을 알게 되었습니다.개발 단계에서는 자동 생성된 ddl을 그대로 이용하기도 하지만, 실제 운영 시에는 최적화를

사용자가 로그인 요청을 보낸 후, 결과(성공/실패)에 따라 적절히 다른 페이지로 이동하도록 API를 작성하던 중 다음과 같은 질문이 생겼습니다.사용자가 로그인에 성공하면 '/', 실패하면 '/login/error' 페이지로 이동한다고 가정해봅시다. 아래의 방법 중 어떤