스프링부트 springboot 와 node.js 관계, IoC 컨테이너, @Validated @NotNull @NotEmpty, public interface, @NotNull(message = "아이디는 필수입니다.", groups = Create.class)

스프링부트 springboot 와 node.js 관계,  IoC 컨테이너,  @Validated @NotNull @NotEmpty, public interface,      @NotNull(message = "아이디는 필수입니다.", groups = Create.class)

 

[백엔드 개발자의 스프링부트 공부노트] springboot 와 node.js 관계

 

실제로 스프링 부트로 백엔드 서비스를 개발하고, Node.js로 프론트엔드 서비스를 개발하는 경우가 있습니다. 이러한 선택을 한 이유는 아래와 같은 장점들 때문입니다.

기술 스택 활용
팀원들이 JavaScript와 Java 둘 다에 익숙하거나, 자바와 JavaScript 각각의 장점을 활용하려는 경우에 각각의 기술 스택을 사용할 수 있습니다.

각 프레임워크의 장점 활용
스프링 부트를 사용하면 Java의 강력한 기능과 다양한 라이브러리 지원을 받을 수 있습니다. Node.js는 단일 스레드 이벤트 기반 처리 방식으로 빠른 응답 속도와 높은 동시 처리 능력을 가지며, 프론트엔드와 백엔드에서 동일한 언어를 사용할 수 있는 장점이 있습니다.

RESTful API를 활용한 분리된 구조
백엔드와 프론트엔드를 분리하여 개발하는 경우, 둘 사이의 통신은 RESTful API를 통해 이루어집니다. 이렇게 각각의 서비스를 독립적으로 개발하면 서로 설정 및 라이브러리 충돌이나 의존성 문제를 유발하지 않습니다.
그러나 Node.js를 사용하지 않는 경우도 있습니다. 이러한 이유는 아래와 같습니다.

통합된 개발 환경 구축
스프링 부트를 사용하여 프론트엔드와 백엔드 모두 개발하는 경우, 동일한 언어와 환경에서 모든 작업을 수행할 수 있습니다. 이로 인해 설정, 관리, 배포의 편의성이 향상됩니다.

유지 보수의 편리함
한 개의 프레임워크를 사용하면 유지 보수 및 개발 속도를 향상시킬 수 있으며, 필요한 라이브러리와 지원들이 통합되어 있어 처음 개발자들이 접근하기 용이합니다.

전체적인 성능 및 안정성
스프링 부트가 서버 사이드에서 안정적이고 강력한 기능을 제공하기 때문에 Java와 스프링 프레임워크 개발에 집중하여 전체적인 성능과 안정성을 향상시킬 수 있습니다.

결국 프로젝트의 요구사항, 기술 스택, 팀 구성원의 역량 등에 따라 스프링 부트와 Node.js를 함께 사용하거나, 한 가지 프레임워크로 전체 시스템을 개발하는 결정을 내릴 것입니다.

 

 

[백엔드 개발자의 스프링부트 공부노트]  Spring IoC 컨테이너

 

Spring IoC 컨테이너

여기서 MessageService 클래스의 생성자에서 Printer 객체가 주입되어 printer 필드에 할당됩니다. 
이러한 방식으로 인해 의존 관계가 주입되며 실제로 코드가 실행됩니다. Spring이 이를 처리하는 방법은 다음과 같습니다.
Spring IoC 컨테이너에 의해 주입되어야 하는 빈과 의존성을 검색합니다.
이 경우, MessageService 및 ConsolePrinter (Printer 인터페이스를 구현하는 구현체)를 찾습니다.
MessageService 생성자의 매개변수로 필요한 Printer 객체를 전달합니다. 이 때, 구현체인 ConsolePrinter 객체가 주입됩니다.
이렇게 주입된 ConsolePrinter 객체를 printer 필드에 할당하여 의존성을 설정합니다.
이 방식을 사용하면, 런타임 시 객체 간의 의존 관계를 명확하게 정의할 수 있고, 코드의 가독성과 유지 관리성이 향상됩니다. 생성자 주입 기법을 사용하여 필수 의존성을 명시적으로 보장할 수 있습니다.

Service의 생성자에서 Repository 객체를 주입받습니다. 최하위 레벨의 객체(Repository)부터 의존성 주입이 필요한 것이 특징입니다.
Repository는 Mapper 객체의 인스턴스를 생성자 주입을 통해 전달받습니다.
최종적으로 Service에서 호출되는 findById 메서드는 Repository에서 호출되어 Mapper에서 구현된 메서드가 실행됩니다. 결국 EmployeeMapper의 findById 메서드는 데이터베이스와 상호 작용하여 원하는 데이터를 반환합니다.
이러한 과정을 통하여, 데이터베이스와 상호 작용하는 코드와 서비스 로직이 별도의 '계층'으로 유지되며, 서로의 영향을 최소화합니다. 따라서 세 가지 클래스의 역할이 명확하게 구분되어 코드의 가독성과 유지 관리성이 향상됩니다.
주석을 추가하면 다음과 같습니다.

java
@Service
public class EmployeeService {
    private final EmployeeRepository employeeRepository; // Repository를 사용해 데이터베이스와 상호 작용할 것입니다.

    // 생성자를 통해 EmployeeRepository 객체를 주입받습니다.
    public EmployeeService(EmployeeRepository employeeRepository) { 
        this.employeeRepository = employeeRepository; // 주입된 객체를 필드에 할당합니다.
    }

    // 서비스 메서드에서 Repository의 메서드를 호출합니다.
    public Employee findById(long id) {
        return employeeRepository.findById(id);
    }
}

이처럼 복잡한 응용 프로그램에서 생성자 주입을 사용하면 객체 간 의존 관계를 더 명확하고 관리하기 쉽게 정의할 수 있습니다. 또한 계층 구조를 통해 코드의 구성 및 가독성을 개선할 수 있습니다.

 

[백엔드 개발자의 스프링부트 공부노트] @Validated @NotNull @NotEmpty

 

@Validated는 스프링 부트에서 제공하는 어노테이션으로, 빈 유효성 검사를 활성화하고, 검사 그룹을 지정할 수 있습니다. 예를 들어, @Validated(User.Create.class)와 같이 사용하면 User.Create 그룹에 속하는 필드만 검사합니다.

 

@NotNull은 javax.validation 패키지에서 제공하는 어노테이션으로, 필드 값이 null이 아닌지 검사합니다. 예를 들어, @NotNull(message = “이름은 필수입니다.”)와 같이 사용하면 이름 필드가 null이면 "이름은 필수입니다."라는 메시지를 반환합니다.

 

@NotEmpty는 org.hibernate.validator 패키지에서 제공하는 어노테이션으로, 필드 값이 null이거나 빈 문자열이 아닌지 검사합니다. 예를 들어, @NotEmpty(message = “이메일은 필수입니다.”)와 같이 사용하면 이메일 필드가 null이거나 ""이면 "이메일은 필수입니다."라는 메시지를 반환합니다.

 

 

 

 

[백엔드 개발자의 스프링부트 공부노트]  @NotNull  @NotEmpty

 

class User {
    
    @NotNull(message = "Name cannot be null") // 이름 필드가 null일 수 없음을 나타냅니다.
    private String name;

    @NotEmpty(message = "Email cannot be empty") // 이메일 필드가 비어있을 수 없음을 나타냅니다.
    private String email;

   // getter and setter methods...
}

위의 코드에서, 만약 클라이언트가 name 필드로 null 값을 보내거나 email 필드를 비워서 보내면, Spring Boot는 자동으로 유효성 검사를 실패하고 400 Bad Request 응답과 함께 에러 메시지("Name cannot be null" 또는 "Email cannot be empty")를 반환합니다.

참고로 실제 프로젝트에서는 에러 메시지와 HTTP 상태 코드 등을 더 섬세하게 처리하기 위한 추가적인 로직(예: 예외 핸들러)이 필요할 수 있습니다.

 

 

 

[백엔드 개발자의 스프링부트 공부노트]  public interface,      @NotNull(message = "아이디는 필수입니다.", groups = Create.class)

 

   // (1) 검사 그룹을 정의합니다.
    public interface Create {}
    public interface Update {}

    // (2) id 필드는 Create 그룹에만 속합니다. 즉, 사용자 생성 시 id는 필수입니다.
    @NotNull(message = "아이디는 필수입니다.", groups = Create.class)
    private Long id;

 

[백엔드 개발자의 스프링부트 공부노트]   API와 클라이언트 간 연결의 서버 쪽 끝

 

엔드포인트란? | 엔드포인트의 정의 | Cloudflare

 

 

 

공격자가 엔드포인트를 표적으로 삼는 이유는?
공격자는 정기적으로 엔드포인트 장치를 탈취하거나 침입하려고 시도합니다. 맬웨어를 이용한 장치 감염, 장치에서 사용자 활동 추적, 장치를 랜섬을 위하여 탈취, 장치를 봇넷의 일부로 사용, 장치를 출발점으로 사용하여 내부망 이동, 네트워크 내의 다른 장치 손상 등 다양한 목표를 염두에 두고 있을 수 있습니다.

비즈니스 환경에서 공격자는 종종 엔드포인트를 표적으로 삼는데, 그 이유는 손상된 엔드포인트가 보안이 잘 갖춰진 기업 네트워크로의 진입점이 될 수 있기 때문입니다. 공격자는 회사 방화벽을 통과하지 못할 수도 있지만, 직원의 노트북은 조금 더 쉬운 표적이 될 수 있습니다.

엔드포인트는 비즈니스 환경에서 보안을 유지하기가 어렵습니다. 그 이유는 IT 팀이 내부 네트워킹 인프라에 비해 엔드포인트에 액세스할 수 있는 권한이 적기 때문입니다. 엔드포인트 장치도 제조사, 모델, 운영 체제, 설치된 애플리케이션, 보안 상태(공격에 대비한 준비 상태)가 아주 다양합니다. 예를 들어, 공격으로부터 스마트폰을 성공적으로 보호하는 보안 조치가 서버에서는 효과가 없을 수 있습니다. 어느 회사에서 어떤 직원은 정기적으로 노트북을 업데이트하고 위험한 온라인 행동을 피할 수 있지만, 다른 직원은 소프트웨어 업데이트를 피하고 안전하지 않은 파일을 노트북에 다운로드할 수 있습니다. 하지만 이 회사에서는 두 노트북을 모두 공격으로부터 보호하고 네트워크가 손상되는 것을 방지할 방법을 찾아야 합니다.

엔드포인트 보안이 어렵고 보호가 중요하므로 엔드포인트 보안은 네트워크 보안, 클라우드 보안, 웹 애플리케이션 보안, IoT 보안, 액세스 제어 등과 함께 사이버 보안의 고유 범주에 속합니다.현재 시중에는 엔드포인트 보호를 위한 다양한 유형의 보안 제품이 있습니다.

엔드포인트 관리란?
엔드포인트 관리는 네트워크에 연결되는 엔드포인트를 모니터링하고, 인증된 엔드포인트만 액세스할 수 있도록 하며, 해당 엔드포인트를 보호하고, 엔드포인트에 설치된 소프트웨어(비보안 소프트웨어 포함)를 관리하는 작업입니다.엔드포인트 관리 소프트웨어는 중앙 집중식으로 사용되기도 하지만, 보안 및 권한 부여 정책을 적용하기 위해 각 개별 장치에 설치할 수도 있습니다.

API 엔드포인트는 어떨까요?
"API 엔드포인트"는 약간 다른 의미를 가진 유사한 용어입니다.API 엔드포인트는 애플리케이션 프로그래밍 인터페이스(API)와 클라이언트 간 연결의 서버 쪽 엔드입니다.예를 들어, 웹 사이트에 운전 경로를 제공하기 위해 지도 제작 API가 통합된 경우 웹 사이트 서버는 API 클라이언트가 되고 지도 제작 API 서버는 API 엔드포인트가 됩니다.이 주제에 대해 자세히 알아보려면 API 엔드포인트란?을 참조하세요.