<aside> ✏️

목차

</aside>

서버 아키텍처를 어떻게 세워야할까?

• xml, html코드, css코드를 아예 파일형태로 해서 스토리지에 저장할까 고민했다.

  • 스토리지에 저장하면 수정사항이 생길때마다 해당 파일을 삭제했다가 다시 생성해줘야하는데 이럼 서버 부담과 비용이 너무 커질 것 같아서..

  → 엔트리는 어떻게 저장되는지 찾아보았다.

• 파일 형태를 3개로 나눈 이유

• 어차피 클라이언트 측에서 블록 수정이 이루어질때마다 실시간 프리뷰 반영을 해줘야하니 xml 코드와 더불어 파싱된 html, css 코드를 계속 들고 있을 것이니 이걸 그대로 저장해줘도 되겠다 생각했다.

  • xml 코드만 저장해줄 경우

    → 워크스페이스 불러와서 화면 렌더링 할 때 시간이 오래 소요될 것이라고 예상

    → xml 코드에서 html코드와 css 코드를 전부 다시 파싱해줘야하니

  • 3개를 분리해서 저장해줄 경우

    → 워크스페이스 정보 불러와서 화면 렌더링할 때 이미 html, css 코드도 받아오니 렌더링 되는 시간이 줄 것이라고 예상.

엔트리는 어떻게 정보를 저장하고 있는가?

• graphQL 사용한다. (요청 보내는 json의 프로퍼티가 너무 많아서 그런 것 같음)

프로젝트 생성

• 기본 템플릿은 클라이언트 측에서 정적인 파일로 가져와서 렌더링 하는 것 같다. (클라이언트 역할)
• 작품 만들기 하자마자 db에 create 요청보내는 게 아니라, 임시로 작품 만들기 페이지를 먼저 보여주는 것 같다.
  • 저장하기 버튼을 눌러야만 새로운 프로젝트 생성 요청을 보낸다.
    • return은 프로젝트 id값으로 돌아온다.
  • 프리뷰 캔버스창 스크린샷을 찍고, 프로젝트 id값을 경로에 넣어서 어디론가 post 요청을 보내는 것은 확실한테 스토리지가 맞는지 아닌지 모르겠다..
    • 아마 사진을 비트화 시키고 암호화 시켜서 보낸 건 아닐까?
      • 요청 헤더의 타입이 json타입이고, 암호화된 것 같은 문자열이 value로 들어간다.
    • 백엔드에서 비트화 시킨 사진을 다시 복구하고 그걸 스토리지에 저장한 후 스토리지 경로를 응답으로 던져주는 것 같다.
• 요청 보낼때 variables
  • 전체
  • 중요한 부분
• 요청 보내는 json객체를 보아하니, 무조건 nosql

⇒ 결론적으로 엔트리는 스크립트 정보를 string으로 변경해서 json 객체에 담아 요청 보냈던 걸로..

• 다만 우리 프로젝트는 저장해야하는 큰 스크립트정보가 3개인 것 같은데 이걸 어떻게 해야하나?
  1. 엔트리랑 똑같이 3개 정보도 그냥 문자열로 변경해서 json 객체에 담아 요청 보내고 그대로 mongodb에 저장하는 방식으로
  2. xml코드만 문자열로 변경 후 script속성값으로 담고 + css 정보는 json 객체로 만들어서 요청
  3. 3개의 파일 전부 스토리지에 저장

→ 개인적인 의견으로는 2번 방법이 베스트일 것 같다.

클라이언트측에선 작품 크기가 커질수록 렌더링 시간 오래걸림 이슈가 있겠지만,

추후 동시편집까지의 확장성을 고려한다면, 스토리지는 쓰지 않아야한다고 생각

→ 동시편집+스토리지 ? 서버 비용이 정말 커질 것 같다.

"cssList":[
	{
		"name": string (css클래스 이름),
		"options":[
			{
				"type":"font-size",
				"value":12,
				"avable":true,
			}
		]
	}
]

엔트리는 임시저장을 어떻게 하는가?

• 엔트리 정보를 저장하는 것에 대해 자동저장에 대한 말이 나왔다.
• 자동저장을 위해서 블록을 둘 때마다 http 요청을 보내면 네트워크에 과부하가 올 것이라고 생각하였고, 웹소켓을 사용하면 어떨까 의견이 나왔다.

엔트리는 웹소켓을 사용하는가?

• 엔트리에도 임시저장 기능이 있다.