HTTP/HTTPS 프로토콜이 아닌 gRPC 프로토콜로 통신하는 서버 프로그램은 API 서버라고 부를 수 있을까요? (배포된 환경, 구현된 기능은 동일)
우리가 일반적인 웹서버라고 하면 데이터베이스에 있는 정보를 가져와서 웹브라우저나 json 타입으로 클라이언트에게 보여주는거라고 생각 할 수 있고 이런 서버에는 보통 php 파이썬 장고 아니면 자바스크립트 노드익스플레스 같은 언어가 통용되어지고 있다.
그런데 이런 일반적인 API서버가 아닌 C++기반만의 활용할 수 있는 기능이 있는 서버가 있다면 이 서버에 인터페이스를 정해야하는데 RESTfull Api 를 사용할수도 있고 다른 것을 사용할 수도 있다. 이런 인터페이스 중 gRPC인터페이스가 있는 것이고 크로스 플랫폼과 크로스 랭귀지 전부 지원해주기 때문에 마이크로 서비스 환경에서 꽤나 괜찮은 인터페이스가 될수 있다.
gRPC server 는 서버측에서 이 인터페이스를 구현하고 gRPC서버를 실행하여 클라이언트 호출을 처리한다. 클라이언트 측에서 클라이언트에는 서버와 통일한 방법을 제공하는 스텁 이 있고 data가 클라이언트 와 서버가 이런방식으로 오고 간다.
세부적으로 들여보면 proto 파일에 정의( service의 정의 request ,response )가 되고
이 파일을 구글 툴을 이용해 헤더를 작성하고 C++기반의 gRPC server가 만들어지고 그 헤더를 이용해 데이터를 채울 수 있다.
만약 파이썬 기반의 서비스와 소통을 하게 할려고 한다면 proto파일에 구글 툴로 이용해 파이썬 파일을 만든다. 이 파일을 클라이언트 측에서 임포트 하게 된다면 gRPC server와 request ,response 가 가능해진다. 이런 동작원리의 gRPC 프로토콜은 규칙을 통한 의사소통이라는 API개념에 비추어 충분히 API 서버라고 볼수 있을것 같다.
단 웹브라우저는 gRPC와의 커뮤니 케이션을 지원하지 않는데 그래서 프론트 앤드 단에서 gRPC를 사용하려 한다면 프록시 서버를 둬야 한다.
Sequlize같은 ORM과 MySQL같은 데이터베이스의 차이가 무엇인가요?
객체지향 프로그래밍은 클래스를 사용하고 관계형 데이터 베이스는 테이블을 사용합니다. 여기서 객체 모델과 관계형모델간에 불일치가 존재하는데 이 객체간의 관계를 바탕으로 SQL을 자동으로 생성하여 불일치를 해결하는것이 ORM 입니다.
Object<=매핑=>DB데이터 여기서 매핑의 역할을 하는것이 ORM
따라서 MySQL같은 데이터 베이스와 Object 간의 매핑을 도와주는 역할을 하는것이 ORM이라고 보면 된다.
express.js의 라우터는 미들웨어입니다. 어떤 원리로 동작하기 때문에 미들웨어로 라우터를 구현할 수 있나요?
선언한 미들웨어를 호출하면 미들웨어는 순서대로 실행되며 모든 요청에서 실행됩니다. 그러나 첫 번째 인수로 주소를 입력하면 해당 주소에서만 실행되며 메서드를 post, get과 같은 메서드로 대체하여 호출하면 해당 메서드 요청에서만 미들웨어가 실행됩니다. 이 처럼 특정 요청과 주소를 특정하여 실행할 수 있는 미들웨어의 동작원리를 활용해 라우팅을 구현할 수 있습니다.
1.express.Router()로 라우터를 import한 다음 처리할 로직을 작성하고 라우터 객체를 다시 export.
2.라우터마다 base가 되는 경로가 있고, 내부 로직을 쓸 때는 subpath만 작성. 정규식을 쓸 수 있고 : 으로 parameter를 가져올 수 있음.
3.express.use()로 basepath와 라우터를 등록해서 사용.
4.콜백 앞에 다른 미들웨어를 끼워 넣을 수 있음. (써드파티 미들웨어, 오류 처리 미들웨어 등)
Node.js에서 리팩토링시 사용하며, npm을 통해 다운로드 했던 모듈을 불러오는 require 함수는 어떻게 동작하나요? IIFE와 연결지어 찾아보고 정리해보세요
https://m.blog.naver.com/jdub7138/221022257248
require 메서드는 자신의 파라미터로 들어온 파일에 들어가 코드를 IIFE로 변환시킨 다음, 새로 만든 module object를 인자로 삼아 IIFE를 실행시키고, module.exports object가 변화하였다면 그 변화를 리턴값으로 그대로 가져온다.
require method는 IIFE를 통한 encapsulation의 원리가 쓰이는데 보호하고자 하는 api들을 function expression으로 둘러싸 외부의 접근을 막되, 접근할 수 있는 방법들이 담긴 object를 리턴하는 구조이다.
A. IIFE 란 Immediately Invoked Function Expression (즉시 실행되는 함수 표현식) 의 약자로 정의와 동시에 즉시 실행되는 함수를 의미합니다.
IIFE는 가장 바깥에 변수를 선언하더라도 함수로 감싸져 있기 때문에 전역에 변수를 선언하지 않고 캡슐화하는 특성을 가지고 있어 전역 스코프를 오염시키지 않기 위해 사용하는 경우가 많습니다.
전역 변수는 몇가지 문제점을 내재하고 있는데
-
내 의도와는 다르게 어디서든지 전역변수를 참조 및 변경이 가능합니다.
-
생명주기가 프로그램의 종료시점과 거의 일치하므로, 이는 상태 변경기회를 늘리게 되며 메모리에도 게속 상주하게 되는 것이므로 리소스도 오랜 기간 소비합니다.
-
스코프 체인 상에서 종점에 존재하므로 전역변수의 검색 속도가 가장 느립니다.
이러한 이유로 자바스크립트는 모듈화를 하려는 시도를 다양하게 하였고 require를 사용하게 되었습니다.
require의 동작은 먼저 파라미터로 받은 경로값에 위치한 파일을 불러오고, module이라는 예약어가 해당 모듈 파일에 module이라는 빈 객체를 만들게 됩니다. 이 빈 객체에서 js파일을 즉시 실행 함수로 둘러친 뒤, 이를 바로 실행시키고 module.exports를 리턴합니다.
이렇게 IIFE의 캡슐화 원리가 require메서드에서도 그대로 쓰이는데 보호하고자 하는 api들을 즉시실행함수로 둘러싸 외부의 접근을 막고, 접근 가능한 object들을 리턴하여 사용할 수 있게 합니다.
불필요한 테스트코드는 무엇이며, 100개의 테스트 케이스보다 1개의 테스트 케이스가 더 효과적일 수 있는 이유는 무엇인가요?
불필요한 테스트코드를 흔히 dead code라고 불리는데, 이는 프로그램 내에서 소스는 작동하지만, 결과적으로는 사용할 수 없다. 이 실행은 계산 되고자 하는 시간과 메모리의 낭비 때문에 여러 버그들을 일으키는 문제가 될 수 있다. 또한, 여러 개의 테스트 코드는 품질 수준이 cost/beneft으로 보았을때, 컴파일된 버전의 리소스에 접근하기 어렵고, 빠른 시간내에 테스트할 수가 없기 때문에 1개의 테스트가 오히려 효과적이다. 더불어 철저하게 테스트 된 케이스가 유효성을 검사하는데 쉽게 접근할 수 있다.
