상세 컨텐츠

본문 제목

[Weekly I Learned] [0501-0505]

카테고리 없음

by Chris_Kwak 2023. 5. 3. 23:22

본문

모의 면접 질문

○ Why use pm2 cluster mode?

높은 가용성 :

Node.js 응용 프로그램의 여러 인스턴스를 실행하면 한 인스턴스가 중단되거나 응답이 없는 경우에도 다른 인스턴스가 수신 요청을 처리할 수 있습니다. 따라서 고가용성을 제공하고 다운타임(서비스가 중단 되는 시간)을 방지할 수 있습니다.

 

향상된 성능 :

들어오는 요청을 여러 인스턴스에 분산하여 Node.js 응용 프로그램의 성능을 향상시킬 수 있습니다. 이는 각 인스턴스가 더 적은 수의 요청을 처리하여 각 인스턴스의 부하를 줄이고 응답 시간을 향상시킬 수 있기 때문입니다.


○ Asynchronous & Synchronous

동기는 요청과 그 결과가 동시에 일어난다는 약속입니다. 요청을 하면 시간이 얼마나 걸리던지 요청한 자리에서 결과가 주어져야 합니다. 비동기 방식은 하나의 요청에 따른 응답을 즉시 처리하지 않아도, 그 대기 시간동안 또 다른 요청을 처리할 수 있는 방식입니다. 동기 방식은 설계가 매우 간단하고 직관적이고, 순서에 따라 진행되는 장점이 있지만, 결과가 주어질 때까지 대기해야 하는 단점이 있고, 비동기 방식은 동기 방식에 비해 복잡하지만 결과가 주어지는데 시간이 걸리더라도 그 시간 동안 다른 작업을 할 수 있으므로 자원을 효율적으로 사용할 수 있는 장점이 있습니다.


○ 객체 지향 프로그래밍(Object Oriented Programming)은 무엇입니까? (취업 스터디)

This image shows an example of the structure and naming in OOP.

 

객체 지향 프로그래밍(OOP)은 실제 엔티티와 객체로서의 동작을 모델링(데이터 모델링은 데이터의 개념적 표현과 다른 데이터와의 관계를 만드는 작업임)하는 데 초점을 맞춘 프로그래밍 패러다임입니다. OOP에서 객체는 데이터(속성)와 동작(메소드)을 캡슐화하는 클래스의 인스턴스입니다.

OOP의 4가지 주요 원칙은 다음과 같습니다:

1. 캡슐화(encapsulation): 데이터(properties)와 동작(methods)을 함께 하나의 개체(오브젝트)로 묶고 잘 정의된 인터페이스를 통해 해당 개체에 대한 액세스를 제어하는 아이디어입니다. 이 원칙은 모든 중요한 정보가 개체 내부에 포함되어 있고 선택한 정보만 노출한다고 명시합니다. 각 개체의 구현 및 상태는 정의된 클래스 내에서 비공개로 유지됩니다. 다른 개체는 이 클래스에 대한 액세스 권한이나 변경 권한이 없습니다. 그들은 퍼블릭 함수나 퍼블릭 메서드의 목록만 요청할 수 있습니다. 이러한 데이터 숨기기 특성은 프로그램 보안을 강화하고 의도하지 않은 데이터 손상을 방지합니다.

2. 추상화(Abstraction): 사물의 본질적인 특징을 식별하면서 그 비본질적인 세부사항은 무시하는 과정. 이렇게 하면 다른 사람이 쉽게 이해하고 사용할 수 있는 개체의 단순화된 모델을 만들 수 있습니다. 개체는 다른 개체의 사용과 관련된 내부 메커니즘만 나타내며 불필요한 구현 코드는 숨깁니다. 파생(derived) 클래스는 기능(functionality)을 확장(extend)할 수 있습니다. 이 개념은 개발자들이 시간이 지남에 따라 추가적인 변경이나 추가를 더 쉽게 할 수 있도록 도와줍니다.

3. 상속(Inheritance): 클래스가 부모 클래스로부터 속성과 동작을 상속할 수 있는 기능입니다. 이를 통해 관련 클래스의 계층을 만들 수 있습니다. 클래스는 다른 클래스의 코드를 재사용할 수 있습니다. 개체 간의 관계 및 하위 클래스를 할당할 수 있으므로 개발자는 고유한 계층 구조를 유지하면서 공통의 논리(common logic)를 재사용할 수 있습니다. OOP의 이러한 특성은 보다 철저한 데이터 분석을 수행하고, 개발 시간을 단축하며, 보다 높은 수준의 정확성을 보장합니다.

4. 다형성(Polymorphism): 개체 사용되는 상황에 따라 여러 가지 형태를 띠거나 여러 가지 행동을 하는 능력. 따라서 코드를 보다 유연하고 재사용할 수 있습니다. 개체는 행동을 공유하도록 설계되었으며 둘 이상의 형태를 취할 수 있습니다. 프로그램은 상위 클래스에서 해당 개체의 각 실행에 필요한 의미 또는 사용법을 결정하여 코드를 복제할 필요성을 줄입니다. 그런 다음 부모 클래스의 기능을 확장하는 자식 클래스가 만들어집니다. 다형성은 다른 유형의 개체가 동일한 인터페이스를 통과할 수 있도록 합니다.

 

OOP는 소프트웨어 개발에 널리 사용되며 Java, Python 및 C++을 포함한 많은 프로그래밍 언어에서 지원됩니다. 코드 유지보수가 용이하고 코드 확장성이 향상되며 실제 문제를 보다 자연스럽게 모델링할 수 있습니다.


○ REST API 는 무엇입니까? (취업 스터디)

어떻게 인터넷에서 정보를 공유할 것인가? 정보들을 HyperText 로 연결합니다.

우선 REST는 Representative State Transfer(자원의 상태를 레프레젠타티브하게 전달)의 약자를 의미합니다.

representative


API(Application Programming Interface)는 HTTP 요청을 특정 엔드포인트로 전송하여 웹 애플리케이션 또는 웹 서비스와 상호 작용하기 위한 인터페이스입니다. 각 엔드포인트는 문서, 이미지 또는 다른 유형의 데이터인 리소스를 나타냅니다. 엔드포인트는 각 리소스를 고유하게 식별하는 URI(Uniform Resource Identifier)로 식별됩니다.

REST API 는 REST 아키텍쳐 스타일을 따르는 API 입니다. REST 는 분산 하이퍼 미디어 시스템(ex: web)을 위한 아키텍쳐 스타일(제약 조건들의 집합)입니다. 따라서 REST API 를 따르려면 REST 에 해당하는 모든 제약 조건들을 만족해야 합니다.

REST Architecture Styles
맨 밑 두 가지

RESTful API는 일반적으로 요청 및 응답에 대한 데이터 형식으로 JSON(JavaScript Object Notification) 또는 XML(Extensible Markup Language)을 사용합니다. JSON은 가볍고 읽기 쉽고 구문 분석하기 쉬우며 대부분의 프로그래밍 언어에서 지원되기 때문에 더 일반적으로 사용됩니다.

 

HTTP 는 WWW(World Wide Web)의 전송 프로토콜로서 이미 이용되고 있었습니다.
Roy Fielding 은 "How do I improve HTTP without breaking the Web?" 이란 질문을 던지고 그 해결 방법을 연구했습니다. 어떻게 하면 웹 생태계를 망가뜨리지 않고 HTTP 를 업그레이드할 수 있을까?

Roy Thomas Fielding

REST(1998), Microsoft Research 에서 발표

"Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction"
분산 하이퍼 미디어 시스템을 위한 아키텍쳐 스타일

REST(2000), 박사 논문으로 발표

"Architectural Styles and the Design of Network-based Software Architectures"

 

An API that provides network-based access to resources via a uniform interface of self-descriptive messages containing hypertext to indicate potential state transitions might be part of an overall system that is RESTful application.
 

REST API는 하이퍼텍스트를 포함한 자기 설명적(self-descriptive)인 메세지의 uniform interface(ex: uri)를 통해 리소스에 접근하는 API 이여야만 한다.

 

REST emphasizes evolvability to sustain an unconrollable system. If you think you have control over the system or aren't interested in evolvability, don't waste your time arguing about REST.

REST는 제어 불가능한 시스템을 유지하기 위한 진화 가능성을 강조합니다. 시스템 전체를 제어할 수 있다고 생각하거나, 진화 가능성에 관심이 없다면 REST에 대해 논쟁하는 데 시간을 낭비하지 마십시오.

 

http 와 json 비교


Wrap Up

○REST 는 긴 시간에 걸쳐서(수 십년) 진화하는 웹 애플리케이션을 위한 것입니다.

REST 를 따를 것인지 API 를 설계하는 이들이 스스로 판단하여 결정해야 합니다.

REST 를 따르겠다면, Self-descriptive 와 HATEOAS 제약 조건을 만족해야 합니다.

  Self-descriptive 는 custom media type 이나, profile link relation 등으로 만족시킬 수 있습니다.

  HATEOAS 는 HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있습니다.

REST 를 따르지 않겠다면, REST API 를 뭐라고 부를 지 정해야 합니다.

  HTTP API

  RESTlike API


 

 

https://www.youtube.com/watch?v=RP_f5dMoHFc&ab_channel=naverd2 

 

댓글 영역