Server State Check

어떤 값이 서버 상태인지 가르는 기준으로 이 글이 제시한 것은?

• 네트워크로 받아 온 값인가
• JSON 으로 직렬화할 수 있는 값인가
• 나 말고 다른 누가 그 값을 바꿀 수 있는가
• 여러 화면이 함께 보는 값인가

받아 온 데이터를 기본적으로 '낡은 것' 으로 치는 설계를 고르는 이유는?

• 그쪽이 실패했을 때 값이 싸기 때문에 — 최악이 요청 한 번 더다
• 요청 수가 줄어 서버 부하가 낮아지기 때문에
• 캐시 메모리를 적게 쓰기 때문에
• 낡음 판정을 생략해 코드가 짧아지기 때문에

주문을 취소한 뒤 목록 캐시를 '지우기' 로 처리하면 화면에 무엇이 보이나?

• 옛 목록이 그대로 남아 취소가 반영되지 않는다
• 목록이 빈칸으로 깜박였다가 다시 채워진다
• 취소한 항목만 회색으로 바뀐다
• 다른 화면의 목록까지 함께 사라진다

입력 중인 글자를 질의 캐시에 넣어 두었을 때 생기는 일은?

• 캐시 열쇠가 매 글자 바뀌어 메모리가 샌다
• 다른 탭에서 같은 글자가 보인다
• 직렬화할 수 없어 예외가 난다
• 배경 재요청이 돌면서 치고 있던 글자를 덮어쓴다

서버 상태에 값과 함께 '받은 시각' 을 저장하는 이유는?

• 그게 없으면 '다시 받아야 하나' 를 물을 수 없기 때문에
• 응답을 시간순으로 정렬해 보여 주기 위해
• 서버와 클라이언트의 시계를 맞추기 위해
• 같은 열쇠의 응답을 구별하기 위해

가르는 선이 흐릿할 때 쓰라고 이 글이 제시한 실전 기준은?

• 값이 200바이트를 넘으면 서버 상태로 본다
• 탭을 두 개 열고 한쪽에서 바꿨을 때 다른 쪽이 따라와야 하면 서버 상태다
• 컴포넌트 두 개 이상이 읽으면 서버 상태로 본다
• 새로고침해도 남아 있어야 하면 서버 상태로 본다