리액트를 쓰는 이유 from 조은의 프론트엔드 실무 가이드 : 요구사항 분석과 적정 기술 난 전문가가 아니니 강사님의 고견을 그대로 수용하도록 하자. 간략하게 보면, 1. 광대한 커뮤니티 - 도움 줄 사람이 많다. 2. 확장성 - 머 사람이 많으니 확장성도 높다. 이미 만들어진 라이브러리가 강력하다 3. 리액트 네이티브 지원 - 앱으로의 확장이 가능하다 4. 경쟁상대 (?) - 상대 우위에 있다는 말씀이신듯... 5. 채용에 유리하다 - 공부하시는 분들이 워낙 많으니깐... 리액트 함수형 컴포넌트의 대두~~~ 함수형 컴포넌트를 쓰는 이유는? Hooks 를 통해 life cycle 을 해결할 수 있다. => 그리고, custom Hooks 를 별도의 함수로 만들고 여러 곳에서 불러 쓸 수 있다. 비즈니스 ..
프론트엔드 개발자가 알아야 하는 구조들 설명 from 조은의 프론트엔드 실무 가이드 : 요구사항 분석과 적정 기술 3가지 정도만 알면 된다고 하시네. 내용은 평이한데 이 구조대로 설계해서 구현하는 것은 별개의 이슈이다 MSA - 마이크로 서비스 아키텍쳐 많이 들어 보던 용어 그냥 서비스를 각각 기능에 맞춰서 작게 쪼개서 작성하자. Micro Frontends 프론트엔드도 MSA 처럼 각각 서비스별로 구현해 두고 iframe 이나 모노레포 방식으로 활용하자. 개념은 비슷한 것이다. 쪼갠다고 무조건 좋은가? 결국 서비스는 모아서 보여지는 것인데 결국 공급자의 고민이 여기에서 많이 되어야 한다. API Gateway 유사하지만, 서비스의 일부 로직, 혹은 데이터 변환, 데이터 정제 필터링 등의 기능을 제공해 ..
렌더링의 마지막 기법으로 SSG 정적 사이트 생성기에 대한 내용을 알아보자. 이 부분은 머 지킬이니 강의에서 언급되는 Gastby 등 여러가지 정적 사이트 생성기 엔진을 알고 있어 어려운 개념은 아니다. 아주 익숙한다. 빌드 당시에 페이지를 만들어 아예 정적 html 페이지 결과를 그냥 올려두고 가져가는 형태이니 Runtime 이라기 보다는 Compile time 빌드라고 생각하면 쉽다. 강의 노트 겸 판서 결과 스샷은 아래를 참고하고, CDN 서비스 등에는 이 방법이 가장 최적화된 방법으로 생각된다. 물론 실행시에 먼가 데이터를 가져오거나 변경해야 한다면 이 방식은 사용할 수 없다. 특정 고정된 콘텐츠의 경우에는 이 방법이 가장 효율적인 방법일 것이다. Gastby 말고 SSR에서 언급한 Next.JS..
이제 서버사이드 렌더링 SSR 에 대해서 간략하게 들은 것을 정리해보자 - from 조은의 프론트엔드 실무 가이드 : 요구사항 분석과 적정 기술 이것도 용어에 적힌 대로 이해하면 된다. 서버쪽에서 렌더링을 해서 html을 내려 보내주므로 클라이언트에서 리소스를 할당해서 렌더링을 할 필요가 없다는 것. 일반적으로 서버의 성능이 아주 빠르므로, 렌더링을 강한쪽에서 해주고 결과만 내려줘서 뿌려주는 역할을 하게 해서 일을 분산 시킬 수 있다는 것이다. 여기에 쓰이는 기술로 소개한 것이 Next.JS 자세한 내용은 더 알아보도록 하고, 이것 말고도 서버사이드에서 렌더링 할 수 있도록 하는 기법으로 - hydrate - React DOM - serverside rendering keyword 가 있다나 머라나 (왜..