본문 바로가기

Develop

[.NET] 레퍼런스 프로젝트 리스트 레퍼런스 프로젝트 리스트 .NET Podcasts Github
[Blazor] Blazor WebAssembly + Webpack + TypeScript + Sass 개발 환경 구축 Blazor WebAssembly + Webpack + TypeScript + Sass 개발 환경 구축 Blazor 를 다른 환경과 통합하여 사용하는 예제를 찾을 수 없어, 직접 연구하여 공유합니다. Blazor 와 관련된 자료는 공식 문서 외에 Awesome Blazor 에서 다양하게 찾을 수 있습니다. 1. 프로젝트 생성 위 그림과 같이 Blazor WebAssembly App 프로젝트를 생성합니다. 생성하면 위 그림과 같은 결과를 얻을 수 있습니다. 현재 상태로 빌드해서 실행하면 위 그림과 같은 결과를 얻게 됩니다. 이제 여기서부터 하나하나 환경을 세팅해보도록 합시다. 2. Webpack 추가 node -v npm -v 현재 프로젝트에 Webpack 을 추가하려면 Node.js 를 설치해야 합니다...
[Blazor] Sass 를 적용하는 방법 Sass 를 적용하는 방법 일단 Sass(Syntactically Awesome Style Sheets) 를 한 문장으로 설명하자면, 스타일을 표현하는 CSS 파일을 프로그래밍 언어처럼 만들 수 있도록 하는 확장 언어입니다. 따라서 Sass 파일을 컴파일하면 결과로 CSS 파일을 얻을 수 있습니다. Sass 는 Node.js 를 바탕으로 npm 으로 패키지를 관리하며 React 로 컴포넌트를 만들고 Webpack 으로 번들링하는 FrontEnd 프로젝트에 빈번하게 사용되며, 번들링할 때 Sass 를 컴파일하여 Css 파일로 만든 뒤 최종 번들에 추가하여 사용합니다. Blazor 에서도 마찬가지로 Sass 를 사용하려면, Sass 를 컴파일하고 최종 결과에 추가하는 과정이 필요합니다. 제일 심플한 방법은 ..
[FE] webpack 에서 Source Map 이 동작하는 원리 Webpack 에서 Source Map 이 동작하는 원리 Visual Studio Code 에서 디버깅하려고 break point 를 잡으면 break point 가 활성화가 되지 않거나 엉뚱한 코드에서 break 가 되는 경우을 종종 겪게 됩니다. 개발을 하다보면 이게 꽤 거슬립니다. 일단 디버깅을 제대로 할 수 없으니 런타임에 어떤 데이터가 저장되고 어디서 어떤 함수가 호출되는지를 console.log() 로 파악하는데 이게 너무나도 고역입니다. 그래서 저는 Source Map 이 어떻게 구성되고 동작하는지를 조사했고 이를 공유드리고자 합니다. Source Map 은 개발하는 코드와 번들링된 코드 사이의 관계를 표현하는 데이터입니다. 이 Source Map 이 필요한 이유는 webpack 을 사용해서..
[FE] Web API - WebSocket API Web API - WebSocket API HTTP/1.1 프로토콜은 클라이언트가 TCP 프로토콜로 서버와 연결한 뒤에 요청을 보내고 서버로부터 응답을 받고 나면 연결을 해제하는 프로토콜입니다. 클라이언트가 요청을 보내지 않으면 서버와 연결되지 않기 때문에 서버가 주도적으로 클라이언트와 통신을 시작할 수 없습니다. 그래서 서버가 클라이언트에게 무엇인가 알려주고 싶어도 방법이 없습니다. 서버 내부적인 변경을 감지할 수 없는 클라이언트가 서버가 원하는 걸 눈치채고 요청을 보내는건 불가능합니다. 그래도 이를 해결하고자 여러 방법이 시도되었습니다. 먼저, 클라이언트가 일정 주기로 서버에게 변경사항이 있는지 확인하는 방법이 제일 직관적이고 구현이 간단합니다. 하지만, 이 방법은 현업에서 사용될 수 없는 방법입니다..
[FE] Web API - Client-side storage : Service Worker API & Cache Web API - Service Worker API & Cache Service Worker 와 Cache 를 활용하면 인터넷 연결이 끊겨도 동작하는 앱을 만들 수 있습니다. Service Worker 는 브라우저에 등록되어, 브라우저와 네트워크 사이에서 프록시 서버의 역할을 수행합니다. 즉, Service Worker 는 서버인 것처럼 브라우저가 서버에게 보내는 요청에 응답할 수 있습니다. Cache 는 브라우저의 Request 와 서버의 Response 를 저장할 수 있습니다. 오프라인에서 동작하는 앱을 만들려면, 먼저 Service Worker 를 등록합니다. 그리고 인터넷이 연결되어 있는 동안, 브라우저가 보내는 Request 와 Response 를 Cache 에 저장합니다. 그리고 인터넷 연결이..
[FE] Web API - Client-side storage : IndexedDB Web API - Client-side storage 브라우저 환경에서 데이터를 저장하는 방법을 시리즈 글로 소개하고 있습니다. IndexedDB IndexedDB 는 클라이언트에 데이터를 저장하는 방법 중 하나입니다. 따라서 네크워크 연결 여부와 관계없이 데이터를 활용할 수 있어, 모바일 플랫폼의 웹 앱에서 활용하기 좋습니다. IndexedDB 는 Cookie 나 localStorage 와 sessionStorage 와 달리 복잡한 데이터를 저장하기 위한 목적의 저장소입니다. 그래서 원리나 사용하는 방법도 다른 저장소에 비해 복잡합니다. 1. IndexedDB 초기화한다. 쿠키는 서버의 Set-Cookie 헤더에서 설정하고 localStorage 와 sessionStorage 는 사용하는 순간 저절로 ..
[FE] Web API - Client-side storage : 로컬 스토리지 localStorage 와 세션 스토리지 sessionStorage Web API - Client-side storage 브라우저 환경에서 데이터를 저장하는 방법을 시리즈 글로 소개하고 있습니다. 로컬 스토리지 localStorage 와 세션 스토리지 sessionStorage 로컬 스토리지 localStorage 와 세션 스토리지 sessionStorage 는 쿠키 Cookie 처럼 브라우저 내에서 Key/Value 로 데이터를 저장할 수 있는 저장소입니다. 로컬 스토리지와 세션 스토리지는 쿠키의 한계를 극복하기 위해 HTML5 와 함께 도입되었습니다. 쿠키는 오래동안 함께 했기에 익숙하고 사용하기 편리한 만큼 여러 한계를 가지는데 대표적인 한계로 서버가 허용하는 HTTP 헤더 크기 이상으로 쿠키에 데이터를 저장할 수 없다는 점입니다. HTTP 프로토콜 설계는 헤더의 ..