1 번에 대한 부분은 추가 언급 하도록 하겟습니다.
2 번에 대한 부분은 관점의 차이가 있을 수 있는데요,
Steemit의 경우 웹페이지를 호출해서 구성을 할때, 자기가 원하는 자료만 호출 하는게 아니라 통채로 전체 자료를 호출해서 그중에 필요한 부분만 체크 하는 형태를 띠고 있습니다.
그러다 보니 보이지 않게 매번 높은 리소스를 요구 하는데요 이번에 분리가 됨으로써 지갑에 관련분 호출 부분은 제외를 할 수 있게 되는 겁니다...
사용자는 신경을 써야 하니깐 리소스가 더 들어간다고 볼 수 있지만, 그냥 steemit은 블로깅 활동만을 하는 곳이라고 생각하시면 ㅎ 좋지 않을까 싶습니다
@ 사파리 웹브라우저 이용 기준
별도 창이 열릴 시, 기존 (www.steemit.com 내) 지갑 과 UI가 크게 차이가 없어서 잘못 인식이 될수 있고 해킹등 문제 발생 이 쉬울 것으로 보여짐
(예를 들어 피싱 사이트? 피싱 지갑을 만들어서 별도의 액션을 할수 있게 시나리오를 만들수 있음)
분리에 따른 장점?이 크게 보여지지 않음 관리를 위한 리소스가 더 많이 들어가는 듯함 (한마디로 불편)
대충 좀 정리하면 두가지를 지금 이야기 할 수 있을 것 같습니다 ^^
1 번에 대한 부분은 추가 언급 하도록 하겟습니다.
2 번에 대한 부분은 관점의 차이가 있을 수 있는데요,
Steemit의 경우 웹페이지를 호출해서 구성을 할때, 자기가 원하는 자료만 호출 하는게 아니라 통채로 전체 자료를 호출해서 그중에 필요한 부분만 체크 하는 형태를 띠고 있습니다.
그러다 보니 보이지 않게 매번 높은 리소스를 요구 하는데요 이번에 분리가 됨으로써 지갑에 관련분 호출 부분은 제외를 할 수 있게 되는 겁니다...
사용자는 신경을 써야 하니깐 리소스가 더 들어간다고 볼 수 있지만, 그냥 steemit은 블로깅 활동만을 하는 곳이라고 생각하시면 ㅎ 좋지 않을까 싶습니다
감사합니다 ^^.
아무래도 IT쟁이고 보안쟁이라 이것저것 생각 하다보니 그렇네요 ㅎㅎㅎ
나름의 MSA형태 이지 않나 하는 생각도 드네요
Micro Service Architecture
별로 Micro 적이진 않은데 ㅎㅎㅎ
지금 상황에서 API를 micro로 구분을 하면 정말 대 공사 일것 같아서...
아마 최소한으로 구분을 한게 아닌가 싶기도 합니다 ㅎㅎㅎ
다만 첫번째 파씽은 저도 상당히 신경이 쓰이더라고요...
그래서 월렛은 그냥 로그인 자체를 하지 않을 생각입니다 ㅎㅎ
필요시... 스팀 커넥터로만 진행 하고요 ㅠ