Technical Questions

javascript

promise의 기능과 필요한 이유.

javascript promise는 비동기 처리에 관한 개선된 방법을 제공합니다. 이전에는 비동기 처리에서 Callback Hell이라는 문제가 존재 하였습니다. 이는 Callback 함수를 중첩적으로 호출하는 경우 코드가 깊어지고 어려워지는 문제였습니다.

 

Promise는 비동기 처리 결과를 처리하는 방식을 표준화하여 코드의 가독성을 높이고 유지 보수성을 향상시킵니다. Promise는 함수의 실행 결과가 반환될 때까지 기다리고, 결과가 반환되면 그 결과를 처리하는 방식입니다.

 

Promise를 사용하면 다음과 같은 장단점이 있습니다.

• 장점
  1. Callback Hell 문제를 해결하여 코드 가독성을 높입니다.
  2. Error Handling이 용이해집니다.
  3. 비동기 처리에 대한 제어가 용이해집니다.
• 단점
  1. 기존에 사용하던 Callback 함수 방식과 다릅니다.
  2. Promise 사용에 대한 기초 지식

 

javascript의 순수함수에 대한 불변성과 사이드 이펙트와 연결한 설명

 

javascript의 순수함수란, 같은 입력 값에 대해 항상 같은 결과를 반환하며, 함수 내부에서 외부의 상태에 영향을 미치지 않는 함수를 말합니다. 순수 함수를 사용하면 코드의 예측성과 안정성이 높아집니다.

 

불변성은 함수의 입력 매개변수나 내부 데이터가 변경되지 않는 것을 말합니다. 순수 함수에서는 입력 매개변수를 변경하지 않기 때문에 불변성을 유지할 수 있습니다. 불변성은 코드의 안정성과 예측성을 높여주어 프로그램의 안정성을 향상시킵니다.

 

사이드이펙트는 함수가 외부의 상태에 영향을 미치는 행위를 말합니다. 순수 함수에서는 사이드 이펙트를 피하여 코드의 안정성과 예측성을 높여야 합니다. 사이드 이펙트는 프로그램의 안정성을 해치고 예측성을 낮추기 때문입니다.

 

React

state와props

state는 컴포넌트의 내부 상태를 나타내며, 사용자 입력과 같은 이벤트에 의해 변경될 수 있습니다. State는 변경되면, 컴포넌트가 다시 렌더링 됩니다.

 

Pros는 컴포넌트에서 사용되는 외부 데이터를 나타냅니다. Props는 부모 컴포넌트에서 자식 컴포넌트로 전달되며, 자식 컴포넌트는 props를 받아서 사용할 수 있습니다. Props는 변경되지 않습니다.

 

즉,state는 내부 컴포넌트의 내부상태를 나타내고, Props는 컴포넌트에서 사용되는 외부 데이터를 나타냅니다. 둘 다 React 컴포넌트에서 중요한 역할을 하지만, State는 동적인 데이터를 나타내고, Props는 고정된 데이터를 나타냅니다.

 

React 컴포넌트의 key 속성

 

React 컴포넌트에서 key 속성은 리스트 형식의 컴포넌트에서 중요한 역할을 합니다.

 

React는 리스트 형식의 컴포넌트를 렌더링할 때, 각 아이템을 빠르게 식별할 수 있는 고유한 키 값을 갖는 것을 권장합니다. 이를 통해 React는 리스트에서 아이템이 추가, 삭제, 순서 변경 등이 일어났을 때, 각 아이템을 효율적으로 업데이트 할 수 있습니다.

 

key 속성에는 각 아이템에 대한 고유한 값을 지정할 수 있습니다. 이 값은 실제 데이터의 ID값이나 인덱스 등이 좋습니다. 이를 통해 React는 리스트의 변경 사항을 적극적으로 최적화 하여, 빠른 업데이트를 제공할 수 있습니다.

 

useEffect의 dependency array

 

React Hook 'useEffect'는 컴포넌트가 렌더링될 때 마다 특정 기능을 실행할 수 있도록 하는 Hook입니다. useEffect의 두 번째 인자로는 'dependency array'를 전달할 수 있습니다.

 

dependency array는 특정 상태 값이나 프롭스가 변경될 때, 그에 따라 useEffect의 기능을 재실행할지를 제어하는 것입니다. dependency array에 포함된 상태 값이나 프롭스가 변경되면 useEffect가 다시 실행됩니다.

 

만약, dependency array에 특정 상태 값이나 프롭스가 포함되지 않으면 useEffect는 첫 번째 렌더링 후에 한 번만 실행되며, 이후에는 재실행되지 않습니다.

 

dependency array를 생략할 수도 있지만, 그럴 경우 매 렌더링마다 useEffect가 실행됩니다. 따라서 가능하면 dependency array를 적절히 지정하여, 효율적인 렌더링을 유지하는 것이 좋습니다.

 

HTTP/네트워크

CSR과 SSR의 차이점

 

CSR(클라이언트 측 렌더링)과 SSR(서버 측 렌더링)은 웹 응용 프로그램이 렌더링되는 방식을 나타내는 두 가지 기술입니다.

CSR: 렌더링은 클라이언트 측에서 수행되며, 이는 HTML, CSS 및 JavaScript가 페이지를 렌더링하기 위해 브라우저에 로드되고 실행된다는 것을 의미합니다.

SSR: 렌더링은 서버 측에서 수행됩니다. 즉, 웹 서버가 HTML을 생성하여 브라우저로 전송한 다음 CSS, JavaScript 및 기타 자산을 로드하여 전체 페이지를 렌더링합니다.

CSR는 클라이언트 측에서 빠르게 렌더링할 수 있기 때문에 사용자에게 더 빠른 사용자 경험을 제공할 수 있다는 장점이 있지만, 초기 로드에서는 더 느릴 수 있습니다. 반면 SSR은 초기 로드에서 더 빠르지만 클라이언트 측에서 렌더링하는 것보다 더 느릴 수 있습니다.

경우에 따라 두 기술을 결합하여 두 세계의 장점을 모두 제공할 수 있습니다. 예를 들어, 응용 프로그램은 초기 로드에 SSR을 사용한 다음 후속 탐색을 위해 CSR로 전환하여 빠른 사용자 환경을 제공할 수 있습니다.

 

GET 메서드와 POST 메서드의 차이점

 

GET 및 POST는 클라이언트와 서버 간에 데이터를 전송하는 데 사용되는 일반적으로 사용되는 두 가지 HTTP 방법입니다.

GET: 이 메서드는 서버에서 데이터를 검색하는 데 사용됩니다. 데이터는 URL의 일부로 전송되며 브라우저의 주소 표시줄에 표시됩니다. 이 방법은 일반적으로 서버의 데이터를 수정하지 않는 단순하고 idententent 쿼리에 사용됩니다. 이것은 안전하고 캐시 가능한 방법입니다.

POST: 이 방법은 일반적으로 데이터를 만들거나 업데이트하기 위해 서버로 데이터를 보내는 데 사용됩니다. 데이터는 요청 본문의 일부로 전송되며 URL에 표시되지 않습니다. 이 방법은 일반적으로 데이터 수정과 같은 더 복잡한 요청에 사용됩니다.

올바른 목적을 위해 올바른 방법을 선택하는 것이 중요하다. GET는 데이터를 더 안전하게 만들고 무단 액세스로부터 데이터를 보호하기 때문에 데이터 수정을 위한 검색 및 POST에 사용되어야 합니다. 또한 GET 요청은 길이 제한이 있으므로 대량의 데이터를 전송하는 데 적합하지 않습니다.

 

웹서버 기초

HTTP 메세지 구조

 

HTTP 메시지는 세 부분으로 구성됩니다:

시작 선: 요청 줄 또는 상태 줄이라고도 하는 HTTP 메시지의 첫 번째 줄은 메시지 유형과 사용 중인 HTTP 버전을 설명합니다. 예를 들어 요청 메시지에서 시작 줄은 "GET/path HTTP/1.1"과 같은 요청 줄의 형태를 취합니다. 응답 메시지에서 시작 줄은 "HTTP/1.1200 OK"와 같은 상태 줄의 형태를 취합니다.

머리글: 헤더에는 전송되는 콘텐츠 유형, 콘텐츠 길이, 인증 정보 및 기타 메타데이터와 같은 메시지에 대한 정보가 포함됩니다. 머리글은 새 줄로 구분되고 메시지의 시작 줄을 따릅니다.

메시지 본문: 메시지 본문에는 텍스트, 이미지, 오디오, 비디오 또는 기타 유형의 데이터인 메시지의 페이로드가 포함됩니다. 메시지 본문은 선택사항이며, 메시지 본문의 존재 여부는 헤더로 표시됩니다. 메시지 본문이 있는 경우 메시지의 헤더를 따릅니다.

단순 HTTP 요청 메시지의 예:

 

GET /path HTTP/1.1
Host: www.example.com
Accept: application/json
User-Agent: MyApp/1.0

단순 HTTP 응답 메시지의 예:

 

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 42

{"message": "Hello, World!"}

 

Same-Origin Policy와 CORS

 

동일 오리진 정책은 웹 브라우저가 구현한 보안 기능으로, 웹 페이지가 해당 페이지가 온 도메인과 다른 도메인에 요청하는 것을 제한합니다. 동일한 원본 정책의 목적은 악의적인 웹 페이지가 사용자 자격 증명이나 쿠키에 저장된 중요한 데이터와 같은 다른 도메인의 중요한 데이터에 액세스하는 것을 방지하는 것입니다.

CORS(크로스 오리진 리소스 공유)는 웹 페이지가 동일한 오리진 정책을 무시하고 다른 도메인의 리소스에 액세스할 수 있도록 하는 메커니즘입니다. CORS는 서버 응답에 HTTP 헤더를 추가하여 리소스 액세스가 허용된 도메인을 나타냅니다. 그런 다음 브라우저는 이러한 헤더를 확인하고 요청을 허용할지 여부를 결정할 수 있습니다.

예를 들어 웹 페이지가 example.com에서 로드된 경우 example.com의 리소스에만 요청할 수 있습니다. 그러나 example.com에서 리소스를 호스팅하는 서버가 CORS를 사용하도록 설정하고 다른 도메인의 요청을 허용하는 경우 웹 페이지는 다른 도메인의 리소스라도 해당 서버의 리소스에 요청할 수 있습니다.

CORS는 서드파티 API를 웹 애플리케이션에 통합하거나 다른 도메인 간에 데이터를 공유할 수 있도록 하는 등 다양한 목적에 유용할 수 있다. 그러나 제대로 구현되지 않을 경우 보안 취약점도 발생할 수 있으므로 CORS를 신중하게 사용하는 것이 중요하다.