사실 어떤 고급스러운 말이나, 교양 있게 저를 표현하는 것에 서툽니다. 미래의 나에게 데이터는 거짓말쟁이다. 수집되다가 거짓말을 치고, 가공하다가 거짓말을 치고, 적재되어서까지 거짓말을 한다. 그나마 믿을만 한게 raw 데이터다. raw 데이터를 가공할 때 최대한 간단한 로직으로 구성하자. raw 데이터도 못 믿겠으면, 적어도 파이프라인 어느 한 곳에서 신뢰할 수 있고 간단한 '거름망' 작업이 필요하다. 문제 해결은 최대한 간단하게 시스템 가뜩이나 크다. 어떤 기능을 추가하는 것보다 빼는게 더 어렵고, 장기적으로 시스템을 가볍게 해야한다. 추가 하기보단 덜어내고, 있는 걸로 쓰는 방법이 가장 우선이다. 예외 처리는 웬만하면 쓰지말자 모르는 에러가 나면 터지는게 맞다. 대응을 그 시점에 당장 못한다면, 로..
HTTP API - 컬렉션 POST 기반 등록 예) 회원 관리 API 제공 HTTP API - 스토어 PUT 기반 등록 예) 정적 컨텐츠 관리, 원격 파일 관리 HTML, FORM 사용 웹 페이지 회원 관리 GET, POST만 지원 대부분 POST 기반의 리소스 등록 시스템을 사용한다(클라이언트가 리소스 URI를 몰라도 되기 때문이다. 회원 관리 시스템(API 설계 - POST 기반 등록) API 설계 - POST 기반 등록 회원 목록 /members -> GET 회원 등록 /members -> POST 회원 조회 /members/{id} -> GET 회원 수정 /members/{id} -> PATCH, PUT, POST PUT은 기존 것을 지우고 덮어버린다. 그래서 PATCH가 나왔는데 이는 부분 수정..
오늘은 초기 설정만 해두면, 굉장히 사용하기 편한 ESLint와 Prettier를 동시에 코드 저장과 함께 자동으로 사용할 수 있는 방법에 대해 포스팅하겠습니다. ESLint & Prettier 먼저 ESLint와 Prettier를 같이 사용하면서, 해당 차이점을 알아야합니다. ESLint는 Linter이고, Prettier는 Formatter입니다. ESLint와 같은 Linter는 소스코드에 문제가 있는지 검사하고, 문제가 있는 부분에 flag를 달아주는 소프트웨어 도구를 말합니다. Prettier와 같은 Formatter는 소스코드를 일관된 스타일로 작성할 수 있게 코드를 변환해주는 소프트웨어 도구입니다. ESLint & Prettier 함께 사용하기 이 둘은 함께 사용해서 문제가 없을 것 같지만,..
진짜 데이터 엔지니어가 된지 거의 두 달이 되었습니다. 처음에 합격 통보가 왔을 때부터 아직도 꿈에 살고 있는 것 같습니다. 정신 없이 회사 일을 배우고, 기술을 배우다보니 시간이 훌쩍 지나갔는데, 이 과정에서 제가 많이 성장했다는 것도 느낍니다. 조금 더 소프트웨어 자체를 넓게 보게 된 것 같고, 그 안에서 쓰이는 세부 기술들도 어떻게 활용해야하는지 많이 배우고, 익숙해졌습니다. 데이터 파이프라인이나, 데이터웨어하우스 관련 기술들에 대해 해보고 싶다는 생각을 많이 했는데, 지금은 CS 지식과, 소프트웨어 설계 이런 것들에 자연스레 더 관심이 많은 것 같습니다. 기초가 튼튼하면, 이해하는게 달라진다고 했었는데, 확실히 기반 지식을 하나하나 배울 때마다 왜 이렇게 코드를 짰는지, 왜 나는 이런 코드 리뷰를..
클라이언트에서 서버로 데이터 전송 HTTP API 설계 예시 클라이언트에서 서버로 데이터 전송 데이터 전달 방식은 크게 2가지 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터(검색어) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 4가지 예시 정적 데이터 조회 : 쿼리 파라미터 미사용 이미지, 정적 텍스트 문서 조회는 GET 사용 정적 데이터는 일반적으로 쿼리 파라미터 없이 단순 조회 가능 정적 데이터 조회 : 쿼리 파라미터 사용 주로 검색, 게시판 목록에서 정렬 필터(검색어) 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용 조회는 GET 사용 GET은 쿼리 파라미터 사용해서 데이터를 전달 HTML Fo..
PUT 리소스를 대체 리소스가 있으면 대체 리소스가 없으면 생성 쉽게 이야기해서 덮어버림 중요! 클라이언트가 리소스를 식별 클라이언트가 리소스 위치를 알고 URI 지정(/members/100) POST와 차이점 PATCH 리소스 부분 변경 PATCH가 지원이 안되는 서버도 있긴하다(요즘은 거의 있다). 그런 경우에는 POST를 쓰면 됩니다. DELETE 리소스 제거
HTTP 메서드(GET, POST) GET : 리소스 조회 POST : 요청 데이터 처리, 주로 등록에 사용 PUT : 리소스를 대체, 해당 리소스가 없으면 생성 PATCH : 리소스 부분 변경 DELETE : 리소스 삭제 기타 메서드 HEAD : GET과 동일하지만 메시지 부분을 제외하고 상태 줄과 헤더만 반환 OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용) CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정(거의 안씀) TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행(거의 안씀) GET 리소스 조회 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달 메시지 바디를 사용해서 데이터를..
HTTP API를 만들어보자 요구사항 : 회원 정보 관리 API를 만들어라. 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 API URI 설계 URI(Uniform Resource Identifier) 회원 목록 조회 /read-member-list 회원 조회 /read-member-by-id 회원 등록 /create-member 회원 수정 /update-member 회원 삭제 /delete-member URI에서 가장 중요한 것은 "리소스 식별" API URI 고민 리소스의 의미는 뭘까? 회원을 등록하고 수정을 조회하는게 리소스가 아니다! 예) 미네랄을 캐라 -> 미네랄이 리소스 회원이라는 개념 자체가 리소스다. 리소스를 어떻게 식별하는게 좋을까? 회원을 등록하고 수정하고 조회하는 것을 모..
모든 것이 HTTP - 한번 더! 모든 데이터들을 HTTP로 보낸다. 바야흐로 HTTP의 시대 http 버전 ~ 요청한거 200 OK야 공백라인 오고 필요한 http 응답 메세지가 들어온다 참고) HTTP 요청 메세지도 html을 가질 수도 있다. 요청 메시지 시작 라인 (요청 메시지) start-line = request-line / status-line request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터) HTTP 메서드 (GET : 조회) 요청 대상 (/search?q=hello&hl=ko) HTTP Version 종류 : GET, POST, PUT, DELETE 서버가 수행해야할 동작 지정 GET : 리소스 조회 POST : 요..
클라이언트 서버 구조 Request Response 구조 클라이언트는 서버에 요청을 보내고, 응답을 대기 서버가 요청에 대한 결과를 만들어서 응답 클라이언트와 서버를 개념적으로 분리를 하고, 비즈니스 로직, 데이터는 전부 서버에 몰아넣는다. 그리고 클라이언트는 UI와 사용성에 집중한다. 그러면 클라이언트와 서버가 독립적으로 진화할 수 있다. UI를 어떻게 그릴지, 클라이언트가 PC, 휴대폰, TV, 아이폰, 안드로이드는 UI/UX를 담당하면 된다. 클라이언트는 딱 거기에만 집중을 하면되고, 비즈니스가 잘돼서 트래픽이 100배 폭주했다면, 클라이언트를 손댈 필요가 없다. HTTP는 클라이언트, 서버 구조인데, 기본적으로 클라이언트가 리퀘스트를 보내면 서버가 응답할 때까지 기다렸다가 응답하면 그거에 따라 움..
HTTP(HyperText Transfer Protocol) 문서 간의 링크를 통해서 연결할 수 있는 프로토콜 지금은 HTTP 메시지에 모든 것을 전송 HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 거의 모든 형태의 데이터 전송 가능 서버 간의 데이터를 주고 받을 때도 대부분 HTTP 사용 지금은 HTTP 시대! HTTP 역사 HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더 X HTTP/1.0 1996년 : 메서드, 헤더 추가 HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전(대부분 기능이 다 들어있음) RFC2068 (1997) -> RFC2616(1999) -> RFC7230~7235(2014) HTTP/2 2015년 : ..
웹 브라우저 요청 흐름 https://www.google.com/search?q=hello&hl=ko DNS 서버 조회(200.200.200.2) HTTPS PORT 생략, 443 HTTP 요청 메세지 생성 소켓 라이브러리를 통해 OS 통해 TCP/IP 계층에 전달을 해야함 SYN, SYN+ACK, ACK 해서 구글 서버와 연결 TCP/IP에다가 패킷을 한번 씌운다. 그럼 이걸 인터넷망으로 던지고, 수많은 노드를 통해가서 구글 서버가 요청 패킷이 도착하면 tcp/ip 패킷을 다 까서 버린다음에 http 메시지를 해석함 구글 서버에서 HTTP 응답 메세지를 만든다. 구글도 응답 패킷을 만들고, tcp/ip 패킷을 또 보낸다. 응답 패킷이 도착하면 웹브라우저에서 이를 HTML 렌더링한다.
