항해 심화주차 2조 gather 사진! :)
팀원분이 알려주신 꿀팁!
이미지 압축 npm: browser-image-compression
이미지 압축은 클라이언트단에서 하면 부담이 너무 커서 서버단에서 해야한다고 한다. 리액트분들이랑 협업할때 이미지 받아와서 압축해서 올리는 방법이라고 합니다!
방법
1. 프론트에서 이미지를 post로 받아온다
2. multer와 aws를 이용해서 aws s3에 서버 단에서 저장한다
3. 그걸 다시 클라이언트가 요청할 때 aws에서 받아와서 클라이언트로 뿌려준다
다음 미니프로젝트 때 써봐야지!
W.A.(Wrapping Assignment)
Q1. Cookie를 쓰신 분도 계시고, localStorage를 쓰신 분도 계신 것 같습니다. 각자 왜 cookie 또는 localStorage를 선택하셨나요?
A. 많은 보안 웹사이트들은 로그인을 한 후 Cookies를 사용해 유저의 신원을 확인하여 모든 페이지에서 재인증을 거치지않아도 되게 됩니다. Cookie는 HTTP요청에 자동으로 데이터를 넘겨주고, LocalStorage와 다르게 header를 안 써도 되기 때문에 cookie를 사용했습니다.
LocalStorage는 Cookies와 달리 모든 HTTP 요청에서 데이터를 주고 받을 필요가 없어서 클라이언트와 서버간의 전체 트래픽과 낭비되는 대역폭의 양을 줄일 수 있습니다. 또한, LocalStorage를 사용하면 문자열 뿐만 아니라 javascript의 primitives와 object도 저장할 수 있고, LocalStorage는 최대 5MB의 정보를 저장할 수 있습니다. (cookies는 4KB이다).
Q2. 웹/앱 어플리케이션을 사용하는 유저들을 보호하기 위한 간단한 정책들은 무엇이 있을까요?
A. 사용자가 유도하지 않은 요청을 실행하게 하는 XSS공격을 막기 위해 데이터를 입력할 때와 출력할 때, 모두 필터링하고, 클라이언트에도 막을 수 있을만한 수단을 구성해놓는 것이 좋습니다. 예를 들자면 간단한 XSS필터를 만들고 모든 파라미터가 해당 필터를 통과하게 하는 방법이 있습니다.
또한 사용자의 비밀번호와 같이 매우 중요한 정보는 반드시 암호화를 통해 원래 암호가 들어나지 않도록 변환해야합니다.
Q3. HTTP/HTTPS 프로토콜이 아닌 gRPC 프로토콜로 통신하는 서버 프로그램은 API 서버라고 부를 수 있을까요? (배포된 환경, 구현된 기능은 동일)
A. gRPC는 구글에서 만든 RPC 플랫폼이며 protocol buffer와 RPC를 사용합니다.
SSL/TLS를 사용하여 서버를 인증하고 클라이언트와 서버간에 교환되는 모든 데이터를 암호화하기 때문에 요청의 무결성을 보장할수 있고. HTTP 2.0을 사용하여 성능과 확장성이 뛰어난API를 지원합니다.
또한 클라이언트 응용 프로그램을 서버에서 함수를 바로 호출 할 수 있어 분산 MSA(Micro Service Architecture)를 쉽게 구현 할 수 있습니다. 서버 측에서는 서버 인터페이스를 구현하고, 클라이언트 호출을 처리하기 때문에(proto Request, proto Response) API서버라 부를수 있습니다.
그렇기 때문에 가능합니다. HTTP/HTTPS가 브라우저에서도 지원하고 범용적이기 때문에 지원하는 API 서버가 일반적일 뿐, 서버와 서버 간으로 gRPC 프로토콜을 이용해 API를 호출하여 제 기능을 다 할 수 있습니다.
Q4. Sequelize같은 ORM과 MySQL같은 데이터베이스의 차이가 무엇인가요?
- ORM은 데이터베이스가 지원하는 데이터 구조를 통해 추상화 레벨을 높이는 역할
- 데이터베이스는 특정 목적성을 가진채 데이터를 더 빠르고 정확하게 관리하도록 돕는 역할
- 때문에 경우에 따라서 AWS S3와 같은 Object Storage도 데이터베이스의 용도로서 사용 가능하다. (Use case에 따라 적합하지 않을 수 있음)
Q5. express.js의 라우터는 미들웨어입니다. 어떤 원리로 동작하기 때문에 미들웨어로 라우터를 구현할 수 있나요?
A. 선언한 미들웨어를 호출하면 미들웨어는 순서대로 실행되며 모든 요청에서 실행됩니다. 그러나 첫 번째 인수로 주소를 입력하면 해당 주소에서만 실행되며 메서드를 post, get과 같은 메서드로 대체하여 호출하면 해당 메서드 요청에서만 미들웨어가 실행됩니다. 이 처럼 특정 요청과 주소를 특정하여 실행할 수 있는 미들웨어의 동작원리를 활용해 라우팅을 구현할 수 있습니다.
Q6. Node.js에서 리팩토링시 사용하며, npm을 통해 다운로드 했던 모듈을 불러오는 require 함수는 어떻게 동작하나요? IIFE와 연결지어 찾아보고 정리해보세요.
A. IIFE 란 Immediately Invoked Function Expression (즉시 실행되는 함수 표현식) 의 약자로 정의와 동시에 즉시 실행되는 함수를 의미합니다.
IIFE는 가장 바깥에 변수를 선언하더라도 함수로 감싸져 있기 때문에 전역에 변수를 선언하지 않고 캡슐화하는 특성을 가지고 있어 전역 스코프를 오염시키지 않기 위해 사용하는 경우가 많습니다.
전역 변수는 몇가지 문제점을 내재하고 있는데
-
내 의도와는 다르게 어디서든지 전역변수를 참조 및 변경이 가능합니다.
-
생명주기가 프로그램의 종료시점과 거의 일치하므로, 이는 상태 변경기회를 늘리게 되며 메모리에도 게속 상주하게 되는 것이므로 리소스도 오랜 기간 소비합니다.
-
스코프 체인 상에서 종점에 존재하므로 전역변수의 검색 속도가 가장 느립니다.
이러한 이유로 자바스크립트는 모듈화를 하려는 시도를 다양하게 하였고 require를 사용하게 되었습니다.
require의 동작은 먼저 파라미터로 받은 경로값에 위치한 파일을 불러오고, module이라는 예약어가 해당 모듈 파일에 module이라는 빈 객체를 만들게 됩니다. 이 빈 객체에서 js파일을 즉시 실행 함수로 둘러친 뒤, 이를 바로 실행시키고 module.exports를 리턴합니다.
이렇게 IIFE의 캡슐화 원리가 require메서드에서도 그대로 쓰이는데 보호하고자 하는 api들을 즉시실행함수로 둘러싸 외부의 접근을 막고, 접근 가능한 object들을 리턴하여 사용할 수 있게 합니다.
참고 할 것: https://m.blog.naver.com/jdub7138/221022257248
Q7. 불필요한 테스트코드는 무엇이며, 100개의 테스트 케이스보다 1개의 테스트 케이스가 더 효과적일 수 있는 이유는 무엇인가요?
A. 불필요한 테스트 코드는 의도치 않게 Input or Output이 바뀌었을 때 검증할 수 없는 테스트 코드이다.
이러한 테스트코드가 100개 있는 것보다 Input, Output의 검증을 명확히 하는 테스트 코드 1개 있는게 테스트코드의 목적성에도 걸맞으며 훨씬 효과적인 테스트코드로 볼 수 있다.
A2. 테스트 케이스는 특정 테스트 목표 / 목표를 검증하기위한 '방법'에 대한 일련의 지침으로, 시스템의 예상 동작이 충족되는지 여부를 알려줍니다.
또한 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향이 존재합니다. 따라서 복합적인 상호작용이 존재하지 않거나 복잡한 구조가 아니거나 크기가 작은 모듈들에 집중적인 테스트코드를 작성하는것은 불필요한 경우가 될 수 있으며,
동일한 테스트 케이스로 동일한 테스트를 사용한다면 나중에는 새로운 결함을 찾아내는데 도움을 줄 수 없습니다. 따라서 정기적으로 리뷰와 개선을 통해 테스트 케이스를 리뷰하고 개선해야합니다.
그리고 완벽하게 테스트코드 검증이 끝나고, 테스트 시에도 아무런 결함이 존재하지 않는다 하여도 요구사항에 부합하지 않으면 품질이 높은 코드라 볼 수 없기 때문에, 이점을 유의하고 코드를 작성해야합니다.
Q8. 자바스크립트 타입스크립트 차이.
A. 자바스크립트는 스크립트 언어이며 타입스크립트는 객체지향 컴파일 언어이다.
타입스크립트는 자바스크립트의 상위 집합으로 자바스크립트의 모든 기능이 있으나 초기 설정이 불편하며 생산성이 낮아질 수 있다.
또한 모든 객체에 대해 타입을 지정해야만 하기 때문에 코드의 가독성이 떨어진다.
자바스크립트에 대해서 잘 모르고 타입스크립트에 도전하는 경우 type을 ANY로 설정하여 기존의 자바스크립트와 비슷하게 사용하는 경우가 생길 수 있어 타입스크립트를 배우기 전에 자바스크립트를 먼저 잘 하는 것을 권장한다.
또한 자바스크립트의 근본적인 오류인 this 맵핑 버그를 여전히 가지고 있어 근본적인 오류에 취약하다는 단점이 있다.
그럼에도 불구하고 협업에서 함수 인자로 전달한 값을 빠르게 찾아낼 수 있는점이나 타입에 대한 설정으로 인해 원인 모를 typeError를 방지 할 수있다는 장점이 있다
Q9. Git ignore가 무었이고 왜 사용하는가?
A. ignore는 기본적으로 왜 사용하는가..
git은 오픈소스로 만들어진 클라우드 저장소이므로 다른사람들이 볼 수 있다 그렇기 때문에 보안에 문제가 되는 정보를 올려서는 안된다. 협업 시 라이브러리 예를들어서 node_modules를 올리면 시간이 너무 오래 걸리기 때문에 협업에서 좋지가 않다 이러한 이유들 때문에 git ignore가 필요하다 git ignore에 git에 올리고 싶지 않은 file들을 명시 해 두면 git 클라우드 저장소에 업로드가 되지 않는다.
Q10. JOI의 정의와 장점
A. Joi는 object schema description language라고 하며 클라이언트 및 서버측 유효성 검사에 모두 사용할수 있는 유효성 검사 라이브러리이다.
Validation을 할때 관계에 따른 내용을 정의 할수 있다.
Joi의 가장 큰 장점은 유용성입니다. 사용하기 쉽고 확장하기 쉬우며 JavaScript의 모든 기능을 갖추고 있습니다.
단점은 프론트 엔드에서 검증 로직을 재사용하려면 백엔드에서 언어를 선택해야 한다는 것입니다.
Q11. SSR & CSR
Single Page Application
SPA는 최초 한번 페이지 전체를 로딩한 이후 부터는 데이터만 변경하여 사용할 수 있는 웹 어플리케이션(하나의 html파일로만 동작함, 리액트 프로젝트 파일도 보면 다 html파일 하나로 작업)SPA는 클라이언트사이드렌더링 방식이다!
Server Side Rendering
서버에서 렌더링을 작업하는 렌더링 방식, 전통적인 웹 어플리케이션 렌더링 방식으로 사용자가 웹 페이지에 접근할 때, 서버에 각각의 페이지에 대한 요청을 하며 서버에서 html, js 파일 등을 다 다운로드해서 화면에 렌더링하는 방식
Client Side Rendering
클라이언트 사이드 렌더링은 SPA로, 클라이언트 사이드에서 HTML을 반환한 후에, JS가 동작하면서 데이터만을 주고 받아서 클라이언트에서 렌더링을 진행하는 것점점 더 복잡해지는 웹페이지를 구현하기 위해서 전통적인 방식의 SSR보다는 CSR로 웹을 구현하는 경우가 많아짐
CSR의 장점
- 클라이언트 사이드 렌더링은 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기때문에 SSR 보다 조금 더 빠른 인터랙션이 가능
- page 전체를 요청하지 않고 페이지에 필요한 부분만 변경하게 하기 때문에, 모바일 네트워크에서도 빠른 속도로 렌더링이 가능
- lazy loading을 지원해줌lazy loading이란 ? 페이지 로딩 시 중요하지 않은 리소스의 로딩을 늦추는 기술(Ex. 스크롤 내려야만 해당 이미지 보이게 하는 것)
- 서버사이드 렌더링이 따로 필요하지 않기때문에 일관성있는 코드를 작성할 수 있음
CSR의 단점
- Googlebot과 Searchconsole에 검색 노출이 되지 않음 (브라우저가 없기때문에, html만 가져와서 검색에는 뜨지 않음)
- 페이지를 읽고, 자바스크립트를 읽은 후 화면을 그리는 시간까지 모두 마쳐야 콘텐츠가 사용자에게 보여지기 때문에 초기구동 속도가 느림.
SSR의 장점
- 사용자가 처음으로 컨텐츠를 볼 수 있는 시점을 앞당길 수 있음
- 검색엔진최적화(SEO) 적용이 용이
SSR의 단점
- 모든 요청에 관해 필요한 부분만 수정하는 것이 아닌, 완전히 새페이지를 로딩하고 렌더해줌(새로고침)
- 전체를 로딩하다보니 CSR보다 느리고, bandwitdh를 많이 쓰고, 사용자 경험 좋지 않음(사용자가 처음으로 컨텐츠를 볼 수는 있으나, 화면단에는 html요소들이 나오나 js파일이 다 다운로드 되지않아서 버튼이 클릭되지않는 등의 현상이 있을 수 있음)
Q12. 설계 개발론 중 대표적으로 BDD(Behavior Driven Development), DDD(Domain Driven Design) 방식이 있습니다. 각각의 특징과 적용 환경은 어떻게 다를까요?
Behavior Driven Development(BDD) - 행동 주도 개발
→ TDD(Test Driven Development), 테스트 주도 개발에서 한 반 덜 나아간 개발 방식.
→ TDD에서는 유닛 테스트로 작성 된 테스트 케이스에 대한 문서를 작성했지만, BDD는 이것을 결합 테스트와 '시나리오 테스트'까지 확장하여 각각에 해당하는 문서를 대체.
→ 시나리오는 어디서부터 테스트를 시작할지, 어떤 것을 테스트하고 어떤 것을 하지 않을지, 한 번에 얼마만큼을 테스트할지, 테스트에 어떤 이름을 붙일지, 테스트가 왜 실패했는지 등에 대한 고민을 해결해줌.
Domain Driven Development(DDD) - 도메인 주도 개발
→ 순수한 도메인의 모델과 로직에 집중.
→ 보편적인 언어의 사용을 추구하며 모든 사람이 이해할 수 있게 문서와 코드가 동일한 표현과 단어로 구성되게 만드는 것.
→커뮤니케이션에 있어 분석 단계, 설계 단계, 구현 단계에 이르기까지 통일된 방식으로 협업이 가능.
→도메인 모델 부터 코드에 이르는 단계가 통일된 규칙을 이룸.
