[WIL] DOM, 서버리스

DOM이란?

문서 객체 모델(Document Object Model)은 HTML 문서(웹페이지)에 대한 인터페이스를 뜻하며, 브라우저가 HTML 웹 페이지를 인식하는 방식을 계층화시켜 트리 구조로 만든 객체 모델이다.

DOM은 이렇게 tree 형식의 자료 구조로 되어 있다. tree형 자료 구조는 하나의 root(뿌리) node에서 시작된다.

tree에서는 위쪽의 노드를 부모(parent) 노드, 아랫쪽 노드를 자식(child) 노드라고 한다.

root node는 가장 위에서 시작되는 node이므로 parent(부모)가 없는 node가 되고, 이를 뿌리(root) node 라고도 부른다.

반대로, children(자식)이 없는 node를 잎(leaf) node라고도 한다. 뿌리(root)에서 시작해서 잎(leaf)에서 끝난다.

 

node(노드) 란?
tree 구조에서 root 노드를 포함한 모든 개개의 개체를 node라고 표현한다.
head, body, title, script, h1, HEADER-1 등의 태그뿐 아니라 태그 안의 텍스트나 속성 등도 모두 node에 속한다.

 

JavaScript는 이 model로 웹 페이지에 접근하고, 페이지를 수정할 수 있다.

 

즉, DOM은 HTML인 웹페이지와 스크립팅언어(JavaScript)를 서로 이어주는 역할을 한다.

 

JavaScript는 어떻게 HTML에 접근할 수 있는 걸까?

바로 document라는 전역객체를 통해 접근할 수 있다.

⇒ JavaScript의 document 객체는 DOM 구조를 접근하는 관문이며, document 객체는 HTML 문서를 나타낸다.

 

왜 HTML에 접근해야 할까?

document객체는 DOM 트리의 root node에 접근하게 해준다.

즉, DOM 트리 안의 다양한 요소(element)와 그 요소의 속성(attribute)에 접근할 수 있다.

tag를 추가하거나 class, id를 추가하고 style도 수정할 수 있다.

DOM은 이용자의 행동에 따라 HTML, CSS를 변경하여 이용자와 상호작용 하기 위해, 즉 웹페이지를 보다 더 interactive하게 만들기 위해 브라우저가 만든 객체이다.

 

DOM 접근 메서드

 

document.getElementById("id명")	해당 id명을 가진 요소 하나를 반환
document.quertSelector("선택자")	해당 선택자를 만족하는 요소 하나를 반환
document.getElementsByClassName("class명")[i]	해당 class명을 가진 요소들을 배열에 담아 인덱스에 맞는 요소를 반환
document.getElementsByTagName("tag명")[i]	해당 tag명을 가진 요소들을 배열에 담아 인덱스에 맞는 요소를 반환
document.quertSelectorAll("선택자")[i]	해당 선택자를 만족하는 모든 요소들을 배열에 담아 인덱스에 맞는 요소를 반환

 

⚠️ 주의할 점
배경색에 대한 style을 지정한다면?
CSS에 익숙한 우리는 background-color 이렇게 작성할테지만,
DOM에서는 backgroundColor 으로 작성해야 한다.
DOM 또한 객체이므로 객체의 기본 속성을 따라가며, 객체의 기본 속성 중에는 프로퍼티 이름에 hypen(-)을 사용할 수 없다는 속성이 있다.
그러므로 style의 프로퍼티에 접근하고 싶을 때는 camelCase로 작성해서 접근해야 한다.

 

변수에 저장하자!

DOM selector를 이용할 때마다, browser는 document 객체에서 element를 찾는 과정을 반복하게 된다.
만일 원하는 element를 변수에 저장하지 않고 계속 DOM selector를 사용하면, 매 단계마다 document 객체를 전부 훑으며 찾기 때문에 메모리 누수가 발생한다.

⇒ 따라서 DOM selector를 이용할 때에는, 선택하고자 하는 element를 항상 변수에 저장하는 습관을 들이자

 

 

---

 

서버리스(Serverless)란?

• 서버리스는 서버가 없다는 뜻이 아니라 직접 서버를 관리하지 않는 경우를 뜻한다. (= Backend without serverless)
• 서버리스를 활용하면 백엔드를 서버에 올리는 게 아닌, 백엔드를 작은 함수단으로 쪼개서 내가 직접 관리하지 않는 서버로 올린다 (ex. AWS lambda)
• 서버리스가 아닌 경우, 서버는 언제나 요청에 응답할 수 있게 24시간 돌아가고 있지만 서버리스 경우, 내가 업로드한 함수는 잠들어 있다가 리퀘스트가 오면 깨어난다. 요청한 작업을 수행 후 다시 잠드는데 이 말은 서버가 24시간 깨어있지 않아도 된다는 말이다.
• 이전에는 유저가 적든 많든 똑같은 돈을 내야했지만, 서버리스의 경우, 사용량에 따라 백엔드 서비스를 제공받고 수행한 함수만큼만 돈을 내면 된다.

 

📌 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 환경의 경우 개발자는 코드 제어 권한이 없는 서비스에 의존해야 할 수 있다.

 

 

서버리스는 언제 써야할까?

• 사이드 프로젝트
• 최대한 빠르게 프로토타입을 출시하고 싶은 경우
  • 개발자 생산성을 높이고 운영 비용을 줄일 수 있다.
  • 서버리스로 작업하면 코드에만 집중할 수 있다.
  • 엄청 빠르게 쉽게 서버를 활용해서 제품을 내놓기 좋다.
• 서버 관리하고 설정에 시간을 아끼고 싶을 때

 

 

💡Reference💡

http://www.tcpschool.com/javascript/js_dom_concept

https://velog.io/@solmii/TIL-DOM%EC%9D%B4%EB%9E%80

https://velog.io/@dwa_all/%EC%84%9C%EB%B2%84%EB%A6%AC%EC%8A%A4%EB%9E%80Serverless