[WIL] 10월 첫째주
React 프로젝트 생성
yarn create react-app newproject #프로젝트 생성!
리액트의 좋은점은 UI에서 바뀐 부분만 업데이트 해줌
변경된 부분만 업데이트된다는게 왜 좋은걸까?
리액트가 아닌 경우, 일반 자바스크립트를 쓴 브라우저는 노드정보가 바뀔때마다 노드트리를 처음부터 다시 생성한다.
5단계에 걸쳐서. 근데 리액트는 가상돔을 써서 우리 시야에 보이는 부분만 수정해서 보여주고 모든 업뎃이 끝나면 일괄로 합쳐서 실제 돔에 던져준다고 한다. 브라우저 작동원리와 연관있다.
프엔은 이 렌더트리 단계를 얼마나 최적화하는가가 중요하다.
변수를 JSX에 전달하는 방법
let counter = 0; 변수를 만들고
Total clicks: {counter} 로 만들어주면
변수의 카운터 숫자에 따라 변화됨
onClick={countUp}
-> 이벤트리스너가 countUp 함수를 호출하고 countUp은 카운트를 바꿔줌
ReactDOM.render()로 container 처음 랜더링 할 때 카운터가 0이므로 0으로 호출됨
그리고 container를 리렌더링을 해줘야 카운터가 +1 상태로 업데이트 됨.
즉, countUp을 호출할 때마다 ReactDOM.render()을 다시 호출해야함
-> countUp에 ReactDOM.render( ) 넣어주기
리액트JS에서 데이터를 저장시켜 자동으로 리렌더링을 일으킬 수 있는 방법
const data = React.useState();를 console.log 시키면
[undefined, f ] -> undefined와 함수가 적힌 배열이 나타남
undefined는 data이고 f는 data를 바꿀 때 사용하는 함수
React.useState() 함수는 초기값을 설정할 수 있음
즉, undefined는 초기값이고 두 번째 요소인 f는 그 값을 바꾸는 함수
배열을 꺼내기
const x = [1, 2, 3]
const [a, b, c] = x;
으로 꺼낼 수 있음
동적인 값 끼얹기, useState
컴포넌트에서 동적인 값을 상태(state)라고 부릅니다. 리액트에 useState 라는 함수가 있는데요, 이것을 사용하면 컴포넌트에서 상태를 관리 할 수 있습니다.
import React, { useState } from 'react';
이 코드는 리액트 패키지에서 useState 라는 함수를 불러와줍니다.
React useState Hook을 사용하는 표준 방법은 다음과 같습니다.
const [count, setCount] = useState(0);
그러나 이 const count 변수는 분명히 다른 기본 값으로 재할당될 것인데 왜 let을 사용해 변수로 정의하지 않았을까?
구성 요소가 다시 렌더링되면 함수가 다시 실행되어 새 범위를 만들고 count 이전 변수와 아무 관련이 없는 새 변수를 만든다.
리액트가 화면을 어떻게 refresh(리렌더링)하는지 알아보자
modifier함수를 이용해 컴포넌트의 state를 바꿀때 컴포넌트는 새로운 값을 가지고 다시 한번 레더링 된다
다시말해 modifier 함수를 가지고 state를 변경할때 컴포넌트가 재생성 된다. 새로운 값을 가지고 리렌더링 되는것이다.
props children으로 컴포넌트안에 컴포넌트 넣기
만들어둔 TestHello컴포넌트안에 TestBox컴포넌트를 넣어보겠습니다.
TestHello.js를 import하고 아래와 같이 TestHello태그안에 TestBox태그를 넣어줍니다.

그리고나서 바로 브라우저를 확인하면

TestHello안의 내용만 나오고 TestBox내용은 나오지 않습니다.
이때 사용하는 것이 props children입니다. 파라미터자리에 {children}을 넣어주고, return할 태그내부에 출력할 컴포넌트인 {children}을 원하는 위치에 추가해줍니다.

그러면 아래와같이 TestHello내용과 TestBox내용이 모두 출력이 됩니다.

onClick 사용 시 함수 넘길 때 주의 사항
https://infiduk.github.io/2022/09/08/react-onclick.html
INFIDUK Blog
성공한 개발자가 되자
infiduk.github.io
서버리스란?

🚀서버리스(Serverless)란?
- 서버리스는 서버가 없다는 뜻이 아니다! 백엔드인데 직접 서버를 관리하지 않는 경우를 뜻한다. (= Backend without serverless)
- 서버리스를 활용하면 백엔드를 서버에 올리는 게 아닌, 백엔드를 작은 함수단으로 쪼개서 내가 직접 관리하지 않는 서버로 올린다(ex. AWS lambda)
- 서버리스가 아닌 경우, 서버는 언제나 요청에 응답할 수 있게 24시간 돌아가고 있지만 서버리스 경우, 내가 업로드한 함수는 잠들어 있다가 리퀘스트가 오면 깨어난다. 요청한 작업을 수행 후 다시 잠드는데 이 말은 서버가 24시간 깨어있지 않아도 된다는 말이다.
- 이전에는 유저가 적든 많든 똑같은 돈을 내야했지만, 서버리스의 경우, 사용량에 따라 백엔드 서비스를 제공받고 수행한 함수만큼만 돈을 내면 된다. (아무 요청이 없으면 FREE😎)
- 서버리스 기능은 응용 프로그램 사용자가 증가하면 확장되거나 복제된다. 저녁 시간에 손님이 많아지면 필요에 따라 식당을 늘릴 수 있는 임대인을 생각해 보면 되는 것.
+)
📌 BaaS(Backend as a Service)
- 개발자가 프론트엔드 코드 작성에 집중할 수 있도록 클라우드 공급자가 데이터 스토리지와 같은 백엔드 서비스를 제공하는 서비스 모델.
- 개발자가 다양한 제3사 서비스와 애플리케이션에 액세스할 수 있게 해준다. 예를 들어, 클라우드 제공업체는 인증 서비스와 추가 암호화, 클라우드 액세스 가능한 데이터베이스 및 상세한 데이터 사용량을 제공할 수 있다. BaaS를 활용하는 경우에는 서버리스 기능은 일반적으로 API를 통해 호출.
- ex) 파이어베이스(firebase)
📌 FaaS(Function as a Service)
- 개발자가 자체 인프라를 유지관리 할 필요 없이 애플리케이션 패키지를 기능으로 빌드, 실행, 관리할 수 있게 해주는 일종의 클라우드 컴퓨팅 서비스. 이벤트 기반 컴퓨팅 실행 모델. 제공업체의 서비스를 사용하여 서버 측 로직과 상태를 관리한다.
- 사전 작성된 서비스 라이브러리에 의존하지 않고 사용자 정의 애플리케이션을 생성하는 개발자에게 더 많은 제어 권한을 제공.
- 스테이트리스(stateless) : 상태(=애플리케이션을 비롯한 모든 항목의 상태란 해당 시점의 상황과 품질, 즉 존재 상태)가 저장되지 않는다. 과거 트랜잭션에 대한 정보 또는 참조가 저장되지 않는다. (server가 client의 상태를 보존하지 x) 각 트랜잭션은 모두 처음부터 시작된다.이러한 스테이트리스 트랜잭션의 가장 일반적인 예시는 검색창에 질문을 입력하고 엔터키를 누르는 형식으로 진행되는 온라인 검색이다.트랜잭션이 우발적으로 중단되거나 종료되면 새롭게 시작하면 된다.
- FaaS 예시
- IBM Cloud Functions
- Amazon의 AWS Lambda
- Google Cloud Functions
- Microsoft Azure Functions(오픈소스)
- OpenFaaS(오픈소스)
🐥 왜 서버리스가 탄생했을까?
- 이전에는 직접 서버를 사야했다. 서버의 하드웨어, 소프트웨어 둘 다 관리를 해야했고 만약 누군가가 코드를 뽑아버리거나 정전이라도 되는 날에는 서버가 다운됐다..ㅠ웹사이트의 트래픽이 증가하고 유저가 들어오면 서버의 메모리가 충분하지 않아서 급하게 메모리를 사와 꽂는 경우도 허다했다.
- 이후 아마존에서 돈을 내면 아마존의 최신 서버를 사용할 수 있는 'EC2'를 선보인다.
- ⇒ 이제 정전이나 사고 등을 걱정하거나 서버가 작다고 마음 졸일 필요가 없게 됐다. 플랜에 따라 아마존에서 스토리지를 늘릴 수 있기 때문!
- 구글, 아마존, MS의 서버를 돈내고 빌리면 그 회사들이 서버의 하드웨어 부분은 관리를 해준다. BUT 서버 소프트웨어는 관리를 직접 해야한다. (보안, 데이터 백업 등등..)
- ⇒ 이 때 등장하는 게 바로 서버리스! 고정된 수의 서버 또는 일정량의 서버 공간을 원격으로 임대할 수 있게 되었다.
- 클라우드 컴퓨팅의 등장
- 클라우드 : 인터넷을 통해 액세스할 수 있는 서버와 이러한 서버에서 작동하는 소프트웨어와 데이터베이스를 의미.
😱 서버리스의 단점
- Cold start : 리퀘스트가 와서 함수를 깨우는데 보통 서버보다는 상대적으로 시간이 걸림. AWS 람다의 경우 어떤 함수가 자주 쓰이는지 파악을 해서 해당 함수는 잠들지 않고 리퀘스트에 빨리 대응할 수 있도록 대응하게 만들었음.
- +) 함수 실행 후 한동안 유지가 되는 상태에서 다른 이벤트가 발생할 시 훨씬 빨리 답할 수 있는데 이걸 warm Start라고 한다.
- 서버 제공자에게 전적으로 의지 : 만약 AWS와 싸우게 된다면 마이그레이팅이 어렵다. AWS에서 서버를 빌렸다가 구글 클라우드로 가는 건 쉽지지만 서버리스에서 이사 가는 건 간단하지 않다. 서버리스로 작업하면 어플리케이션의 구조 자체가 바뀌게 된다.
- 클라우드 제공업체는 자사 구성 요소가 상호작용하는 방법을 엄격히 제한할 수 있어, 사용자 시스템의 유연성과 커스터마이징 수준에 영향을 주게 된다. BaaS 환경의 경우 개발자는 코드 제어 권한이 없는 서비스에 의존해야 할 수 있다.
🧐 서버리스는 언제 써야할까?
- 사이드 프로젝트!
- 최대한 빠르게 프로토타입을 출시하고 싶은 경우
- 개발자 생산성을 높이고 운영 비용을 줄일 수 있다.
- 서버리스로 작업하면 코드에만 집중하면 되기 때문에!(설정은 신경 안써도 된다.)
- 엄청 빠르게 쉽게 서버를 활용해서 제품을 내놓기 좋다.
- 서버 관리하고 설정에 시간을 아끼고 싶을 때