[3/29] 프레임워크와 라이브러리, 캐시

프레임워크와 라이브러리 차이점에 대해 설명해주세요.

📌 제어 흐름의 주체

📌 개발자의 역할

• 프레임워크: 코드를 적절한 곳에 넣어줘야 하는 것 → 프레임워크가 정해준 방식대로 구현 ⇒ 프레임워크에 의해 적절한 시점, 상황에 자동으로 호출
  • 개발자가 작성한 코드를 실행하는 주체; 프레임워크가 제공하는 제어 흐름에 따라 코드를 작성해야 함
  • 장점
    • 개발 생산성 향상
      • 구조 설계 및 개발 시간 단축
      • 컴파일, 빌드 등 반복 작업의 자동화
    • 안정성, 확장성 보장
      • 검증된 코드를 제공하기 때문에 버그, 오류 감소
      • 보안, 데이터 무결성 등의 처리 방법이 이미 정의되어 있음 → 고려하지 않아도 됨
      • 다양한 라이브러리, 플러그인 지원
    • 유지 보수성
      • 표준화된 방식으로 개발 진행 → 협업, 유지 보수에 도움
  • 예시: Django, Ruby, Next.js
• 라이브러리: 우리가 원할 때마다 부르고 사용할 수 있는 것 → 특정 기능을 수행하는 도구를 필요할 때마다 직접 호출
  • 작성한 코드에서 라이브러리를 호출하는, 사용자가 제어 흐름을 관리하는 방식
  • 장점
    • 개발 생산성 향상
      • 필요한 기능을 직접 구현할 필요가 없음
    • 유지 보수성 향상
      • 라이브러리는 개발자의 구현 코드와 독립적으로 작동하므로 코드 수정 시 고려 사항에 넣지 않아도 됨
    • 다양한 옵션
      • 같은 기능을 가진 라이브러리들 중 개발자가 선택하여 적용할 수 있음

캐시의 장단점과 어떤 부분에 활용하는지 설명해주세요. 프론트엔드에서 캐시를 사용할 수 있는 2~3가지 영역을 제시해주세요

cache: 임시저장소

장점

1. 빠른 액세스 속도; 메모리나 하드드라이브와 비교하여 적은 용량 사용 → 빠른 속도
2. 성능 향상; 미리 저장해둔 데이터를 다음 액세스 때 빠르게 처리하므로 시스템 성능 향상에 도움

단점

1. 용량의 한계; 시스템에서 사용되는 데이터 양에 따라 캐시 저장 용량이 한계에 도달할 수 있음
   1. 캐싱 데이터의 빈번한 변경 → 성능 저하
2. 데이터 불일치; 캐시 데이터와 실제 데이터의 불일치
   1. 캐싱 데이터가 오래된 경우 발생 → 업데이트를 위한 추가 처리가 필요

Web cache(proxy server)

클라이언트는 HTTP request 를 proxy server에 보낸다 → proxy server가 original server에 HTTP request를 대신 보낸다.

왜 사용할까? 💡 proxy server에 웹페이지를 cache 하기 위해

ex) 다른 클라이언트가 프록시 서버로 요청을 보냈을 때 이미 캐시에 저장된 페이지라면 프록시 서버에서 바로 response를 보내줄 수 있다. → 응답 시간 단축

캐시 관리: Response Header에 Cache-Control 설정

no-cache: 캐시 사용 전 서버 검사 후 사용 결정
pulic: 모든 환경에서 캐시 사용 가능
private: 브라우저 환경에서만 캐시 사용, 외부 캐시 서버에서는 사용 불가
max-age: 초 단위의 캐시 유효 시간

• HTML: no-cache; 항상 최신 상태를 유지하지만 일정 부분의 캐시를 둠 (사용하지 않는다는 의미x)
• JS, CSS, Image 각 리소스 별로 설정
  • max-age: 3156000 (1년을 초로 환산한 값 - 사실상 무한대)