티스토리 뷰

728x90

[ 밑줄/연결 ]

 

(11. 라이브러리와 프레임워크, 비슷한 거 아냐? )

 

공통점 : 개발 속도를  더 빠르게 만들어 준다.

누군가가 미리 작성해 놓은 코드이고, 우리의 개발 속도를 더 빠르게 만들어 주는 도구라는 점이 같다.

 

차이점 : 내가 제어하는가, 제어당하는가? 

여러분이 어떤 도구에 대해서 모든 결정을 다 내리고 있다면? 그 도구는 라이브러리.

jQuery는 자바스크립트보다 더 쉬운 방법으로 웹 사이트에 인터랙티브한 요소를 넣을 수 있게 해주고, bootstrap은 웹 사이트의 화면을 구성할 때 메뉴/버튼/레이아웃과 같은 것들을 편하게 구현할 수 있게 해줘.필요할 때 불러서 쓸 수 있음. 다른 라이브러리로 쉽게 대체할 수 있음라이브러는 제어권이 나에게 있고, 교체 난이도가 매우 쉽다.

 

누군가 정한 규칙에 따라 도구를 사용하고 있다면? 그건 프레임워크

우리는 프레임워크를 부를 수 없음. 프레임워크가 우리를 부름. 우리를 제어함프레임워크를 사용해서 코드를 작성할 때는 프레임워크의 규칙을 따라야 함. 코딩 규칙, 파일 저장 규칙 등 등웹 개발을 위한 프레임워크인 장고(Django)와 스프링(Spring)이 대표적

중요한 것은 규칙을 바꿀 수 없다. 예) 장고로 운영자 페이지를 만들고 싶다면 무조건 이름이 admin.py인 파일에 코드를 작성해야 함.

 

장고로 개발했던 프로젝트를 스프링으로 바꾸고 싶다면!  모든 것을 교체해야 함. 폴더 이름, 파일 구성, 코드까지 모두 다...

그래서 프레임워크를 신중하게 결정해야 함

프레임워크는 제어권이 나에게 없고, 교체 난이도가 매우 어렵다.

 

 

(13. 그놈이 API, 대체 뭐길래? )

 

키보드는 컴퓨터와 사람이 대화할 때 다리 역할을 함.

사람이 컴퓨터와 소통을 할 때 키보드를 쓰는 것처럼 프로그램끼리 소통할 때 쓰는 일종의 규칙을 코드화한 걸  API라고 함

 

API는 프로그램끼리 소통하도록 도와줌

'저장' 버튼을 누르면 '어디어디 데이터베이스를 찾아가서 어떻게 저장하라'와 같은 연결 역할을 해줄 녀셕이 필요함.

이것이 바로 API임

 

날씨 API는 날씨 데이터베이스에 있는 정보를 우리에게 제공함.

 

웹 API의 마이크 접근 기능을 사용하면 크롬 브라우저와 마이크를 연결하는 코드를 여러분이 직접 만들지 않아도 크롬 브라우저에서 마이크 기능을 간단하게 사용할 수 있음. 카메라도 마찬가지임

 

API 작동 방식의 특징은? 사용하는 사람은 알 수 없다는 것!

우리는 그저 API가 제공하는 결과만 보는 것임

그저 API를 사용해서 사용자의 위치만 가져오면 됨. 원리까지 알아야 할 필요는 없음

 

 

(20. 그슈퍼 개발자만 할 수 있다, 풀 스택 ? )

 

풀스택은 프론트엔드, 백엔드, 데브옵스다.

 

프론트엔드

사용자가 보는 화면의 인페이스를 의미함. UI. 

사용자와 상호작용하는 것을 의미함

HTML, CSS, 자바스크립트, 리액트, jQuery,  Vue.js 등 다양한 기술로 사용자와 상호작용

 

백엔드

사용자가 눈으로는 볼 수 없지만 실제로는 사용해야 하는 기능

예를 들어 계정 생성, 동영상 업로드, 댓글 저장 기능 등....

PHP, 자바, 파이썬, 자바스크립트, C#  등

 

데브옵스 

개발하고 서버를 고르고, 설정하고, 서버에 SW를 설치하고, DB설정하고, 보안......이 모든 것을 데브옵스라 함

 

프론트엔드, 백엔드, 데브옵스를 모두 할 수 있는 사람을....풀스택 개발자라고 함

 

 

(21. 서버리스는 서버가 없다는 뜻 ? )

 

있기는 있지만 우리 곁에는 없는 서버, 서버리스

우리가 직접 관리하지 않는 서버를 의미함

아마존의 등장으로 서버는 우리 곁을 떠났다. EC2

아마존, 구글,  MS의 각종 클라우드 서버....HW를 제공,관리해 줄 뿐이고 서버의  SW 관리는 여전히 우리가 해야 함

서버의 운영체제 업데이트, 보안 점검, 장애 회복 시스템 구축, 데이터 백업 등 해야 할일이 엄청 많음. 이래서 서버리스가 등장함

 

서버리스, 서버 제공부터 서버의 SW 관리 그리도 더!?

여러분의 서버를 위한 SW(백엔드 코드)를 작은 함수 단위로 쪼개. 

그리고 그 함수를 서비스(서버)에 올림

그리고 이 함수들은 서버에서 항상 깨어 있지 않음

함수가 자고 있다가, 필요할 때(요청) 깨워서 요청한 작업을 수행함

서버리스는 여러분이 등록한 함수가 실행된 만큼만 돈을 내면 됨

 

서버리스의 2가진 단점

(1) 서버리스의 함수는 잠에서 깰 때 시간이 필요함 : 콜드 스타트

24시간 온라인을 제공하는 서버보다 응답 시간이 조금 더 필요함. 

응답 시간은 밀리초 단위인데 그 시간도 중요한 서비스라면 서버리스는 좋은 선택이 아닐 수도 있음

 

(2) 서버 제공자에게 지나치게 의존함

서비리스를 사용하고 있다면  AWS와 결혼한 것과 같음

단순히 함수를 빼서 다른 서비스로 이사갈 수는 없음.

편리한 만큼 함수의 형태가 서비스에 딱 맞아 떨어지는 형태여서, 지금 사용하는 서버리스 서비스에서 다른 회사의 서버리스 서비스로 옮기기는 쉽지 않음

 

사이드 프로젝트를 하는 사람이나 프로토타입을 최대한 빠르게 출시하고 싶은 기업에서 사용함

 

 

(40. REST API라니, 휴식 API인가 ? )

 

Representation State Transfer의 준말본질은 어떤 설계 규칙....즉, REST방식으로 설계한  API를 말함

 

HTTP 메서드란 웹 기술을 뜻하는데, 같은URL로 백엔드에서 다른 처리를 할 수 있도록 일종의 갈림길을 만들어 주는 것대표적으로 GET, POST, PUT, DELETE가 있음

기능을 확장하기에도 좋음. 예를 들어 영화 <인셉션>의 배우 정보를 조회하는 API늗 다음처럼 설계가능

GET/movies/inception/actors

 

평점 4.5 영화를 조회하려면 어떻게 설계? 

GET/movies? min+rationg = 4.5

 

 

[ 자평  ] 책의 컨셉에 딱 맞게. 잘 썼다. 

 

 

댓글