일단 @code로 스크립트를 자바스크립트 안 쓰고 


C# 쓰니까 좆나 편하고 생산속도 빠르긴함


근데 브라우저에 띄워보면 반응속도가 무슨 랙걸린 게임하는 느낌이 듦


--------------------------------


다음은 내가 잘못 이해해서 오해하고 있을 수 있지만 암튼 알아본 바로는...


Blazor Server App은 SignalR(웹소켓)로 상태 유지를 하는데 이 소리인즉 뭔가 주고받으면 이게 메시지 1회씩 계속 누적될테고 그러면 곧 돈 나간다는 소리임. 


Azure 프리티어에서는 20개의 동접과 하루 2만개 메시지라는데 200만개도 아니고 2만개? 뭔 버튼하나 클릭할 때마다 메시지 보내서 상태 유지할텐데 2만개만 그냥 테스트 용도임


유료 티어는 유닛당 동접 1천개, 메시지는 유닛당 매일 첫 1백만개 무료이고 유닛당 하루에 2천원꼴, 메시지는 1백만개에 1달러씩


코드가 서버에서 실행되니까 서버 리소스도 많이 먹음


채팅앱 같은 목적 아니면 딱히 용도가 없을 거 같음


CPU 1개, 3.5GB 램에서 지연시간 0.2초내로 동접 5천개 처리한다는데 .net 비동기 처리 성능이 좋긴 좋나봄


그래서 블레이저 서버 앱 말고 웹어셈을 알아보면


-----------------------------------


Blazor WASM App은 기존 웹앱처럼 앱구동에 필요한 파일을 모두 클라이언트(브라우저)에게 전송함


다만 WASM 앱이니 CLR, 참조하는 어셈블리 파일들도 보내는데 이게 릴리즈모드에서 약 2~3MB


(기본 설정을 건드리지 않았다면)브라우저에서 캐싱을 할테지만, 최초 초기 구동은 로딩 시간이 느려질 수밖에 없음


System.Net.Http.dll, System.Core.dll 등등 링커가 사용하는 어셈블리 파일들을 선택하는데 이것들 MS에서 오픈해서 대신 쏴주면 안되나?


MS는 Azure 클라우드 사업으로 글로벌 여기저기 CDN 서버 많으테니까 블레이저 밀어주지?


WASM 모델은 Server 모델에 비해 퍼포먼스가 더 좋음


C# 코드가 브라우저로 전송되어 실행되니 보안 측면에서는 Server보다 못하지만 이건 js로 웹페이지 짜도 마찬가지이니 상관없음


웹API 호출해서 데이터 요청하면 됨


--------------------------------------


솔직히 바닐라 js도 쓰기 싫고, 리액트 뷰같은 js 프레임워크, 라이브러리들도 별로라서 


WASM 모델, 갓샵으로 웹페이지 만든다면 매우 편리할 거 같긴함


많이 땡기는데 방문자마다 처음에 어셈 파일들 2~3MB씩 쏴주는 그 트래픽과 그 시간이 발목 잡네


결론 : ㅇㅇ 그냥 하던대로 프론트에선 js 쓸게...