FrontEngineer JungBam

세가지 방법 모두 request에 따른 response 이후에 연결이 끊어지는 HTTP의 단점을 보완해 줄 수 있는 방법으로 제시할 수 있으나, 각각의 차이가 있다. 아래의 표로 간단하게 살펴보자. 구 분 웹 스토리지 쿠 키 로컬 스토리지 세션 스토리지 특 징 - HTTP 요청이 끝나더라도 서버 상태를 유지할 수 있는 저장소 역할을 함. - 한 사이트당 4kb, 20개의 문자열 정보만 담을 수 있음. - 서버에 요청될때 무조건적으로 실려서 보내짐. - 영속성을 가져 브라우저를 닫더라도 유지가 됨. - 기본적으로 쿠키 세션과 동일하게 브라우저를 닫으면 데이터가 지워짐.

HTTP란? HTML과 같은 하이퍼미디어 문서를 전송하기 위한 애플리케이션 레이어 프로토콜 (HTTP는 기본적으로 TCP/IP 기반 프로토콜) HTTP 메시지 (구조 : start line - headers - black line - body) - request는 클라이언트가 서버에 보내는 요청 start line의 method에 요청 의도를 담고 있고, headers에는 쿠키를 포함한 추가정보를 담고 있다. body에는 request에 전송하는 데이터를 담고 있다. - response는 이 request에 대한 응답으로 서버가 클라이언트에 보내는 메시지 start line에는 Status Code를 포함한 정보를 갖고 있고 body는 서버에서 클라이언트로 보내는 데이터가 담겨있다.

캐시란? 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시장소를 이야기 한다. - 장점 : 자주 사용되는 데이터나 반복되는 연산에 대하여 원래 데이터를 접근하는 것보다 빠르게 꺼내서 사용할 수 있다. - 단점 : 임시로 저장하는 과정에서 리소스가 사용되기 때문에 불필요한 캐시가 많다면 역으로 캐시 메모리가 늘어남에 따른 저장 공간의 낭비가 될 수 있다. HTTP 캐시 사용하기 서버에 요청되어 얻어진 값을 캐싱할 수 있는데, 웹 브라우저가 요청하는 리소스가 캐시에 있다면 서버에 요청을 보내지 않고 캐싱되어 있는 리소스를 읽어와 사용하게 됩니다. 이는 서버에서 Cache-Control에 max-age를 설정하여 관리할 수 있습니다. webpack 캐시 사용하기 webpack에서 번들링하는 과정에서 브라우..

프레임워크란? 전체적인 흐름을 스스로가 주도하는 경우를 이야기합니다. 쉽게 말하면 프레임워크가 정해놓은 양식과 규칙을 사용자가 따라야 하는 것입니다. 라이브러리란? 전체적인 흐름을 주도하는 것이 라이브러리 스스로가 아닌 사용자에 있습니다. 즉, 사용자가 라이브러리를 사용자의 입맛에 따라 쉽게 변경하고 다른 대체 라이브러리로 사용할 수 있다는 것입니다. 그렇다면 React는 프레임워크일까? 라이브러리일까? React의 라이프사이클을 사용자가 조작하여 흐름을 바꿀수 있는 점에 있어서 React는 라이브러리라고 생각을 한다. 공식 홈페이지에서 또한 라이브러리라고 소개한다.

webpack 연습 : https://github.com/studyTS-bam/webpack-prac 가이드를 따라서 연습하면서 각각의 커밋을 통해 각 챕터를 나눠서 해봤다. CRA와 barbel을 알고 있었음에도 그 동작원리에 대해서 자세히 보지 않은 것에 대해서 이제와서라도 보게 된것에 다행이라는 생각이 든다. 번들링이 어떤 작업을 하는지.. CRA가 왜 좋은지에 대한 생각이 많이 들었다. 프로젝트의 성능 최적화를 하기 위해서 '코드 스플리팅'에 대하여 공부하다가 webpack까지 와서 공부하면서 개발을 할 때에 고민해야 하는 점이 더 늘게 되어 기쁘다. 아는만큼 보인다고 했었던가, 점점 보이는 것이 늘어가고 공부할 것이 늘어가는 것 또한 얼마나 설레이는 일인지. 리액트의 번들링 관련되어 아래 글을 ..

리액트 최신버전에서는 특정 번들링 최적화가 필요없다고 이야기는 하지만 또 어떤 부분에 있어서는 번들링 최적화를 만져줘야하는 부분이 있다. 예를 들면 lodash의 경우에는 번들링 최적화가 필수적이라고 들었다. 그래서 번들링 최적화 중 가장 많이 들어본 webpack에 대해서 공부를 시작하기로 했다. 그렇다면 번들링이란 무엇일까? 번들이라는 말에서와 같이 하나로 묶어주는 작업을 이야기하는데, 묶어주는 작업에 있어 모듈들의 의존성 관계를 파악하여 이에 맞게 그룹화해준다. 그럼 애초에 하나로 작업하면 되지 않나? 하나에서 작업할 때에는 작업의 효율성이 떨어지기 때문에 각각의 기능별로 모듈화를 시켜주게 되었고 이를 하나로 합칠 때에 불필요하게 다 그룹화하는 것이 아니라 의존성이라는 서로의 관계를 고려하여 묶어주..

조회수를 구현하고 나니까 조회수를 정신없게 올리는 것에 대한 처리가 필요하다는 생각이 들어서 이것저것 해보면서 느낀점이 있다. 예전 사이드 프로젝트에서 빽분이 말씀하셨던 게 생각났다. '아~ 무조건 빽에서 해야지. 그걸 왜 프론트에서 만져. 그거 냅둬' 그때는 뭣도 몰랐으니까 아네 하고 말았지만, 이번에 프로젝트하면서 똑같은 주제가 나왔을 때 그 때 그분이 한 이야기를 하나씩 팀원들한테 하다보니까 찾아보게 되었고 왜 그렇게 말씀하셨는지 알게 되었다. 생각해보면 당연한 것을.. 프론트에서 쿠키에서 작업을 하면 결국 클라이언트가 쿠키에 접근해서 조작할 수 있다는 가장 큰 단점을 갖고 있기 때문. 작업하는 건 어렵지 않고 오히려 지금은 코드짜는 것이 좋지만 보안에 있어서는 빽이 하는 것이 맞는 것 같다. 아래..

/board 에서 post 요청을 하고 다시 /board로 보내고 새로고침을 하게 되면 아주 신기한 일이 생긴다. 똑같은 입력의 반복 ㅎㅎ 왜그런지 이유를 찾던 중 네트워크로 새로고침이 될때마다 다시한번 POST 요청이 보내지는 것을 알게 되었고 url을 보니 모든 것이 이해가 되었다. @app.route("/post/board", methods=["POST"]) def board_post(): title_value = request.form["title"] content_value = request.form["content"] now = dt.datetime.now() doc={ # 유저 값 토큰에서 받아서 넣어야 함. 'title' : title_value, 'content' : content_val..