(장준영) Vanilla JavaScript로 SPA 구현하기 - 식당/카페 여석 확인 어플리케이션 [에 대한 회고록]

프로젝트의 목적 

이론으로만 알고있던 CSR과 SPA 를 직접 만들어보며

SPA의 장점을 느껴보고싶었다

SPA가 주는 장점 중

서버 부하를 줄여주는 장점을 느껴보고싶었다 

---

프로젝트를 진행하며 고민한것

1. SPA를 위해서 브라우저로 보낼 JSON 데이터는 어떤식으로 구성해야 효율적일까?

CSR 에 필요한 모든 데이터를 한번에 다 보내는게 효율적이다,

데이터베이스도 이에 따라 임베딩 방식으로 디자인 하는게 효율적이다

 

2. CSR 과 SPA 가 어디에나 다 어울리는가 ?

인터렉션이 매우 자주 일어나고, 그에따라 즉각적으로 최신 데이터가 필요한 경우에 안 어울린다,

SSR은 지금 당장 화면을 렌더링하는데 필요한 데이터만 있으면 되지만,

CSR은 거의 모든 화면을 렌더링하는데 필요한 데이터를 전부 필요로 하기때문에,

인터렉션 마다 데이터를 CRUD하고, CRUD하지 않은 데이터들까지 전부 다 다시 브라우저로 보내줘야해서

인터렉션이 잦고, 인터렉션 마다 많은 데이터를 가져와야하는 만큼 비효율적이다

 

3. 프론트엔드에서 할 수 있는 최선은 어디까지일까? 어디까지가 프론트엔드의 역할일까?

나는 프론트엔드가 극한의 효율을 위한 열쇠라고 생각했다

예시상황을 생각해봤다, 회원가입을 위해 아이디 중복검사를 진행해주어야한다

브라우저로 회원들의 아이디 정보를 보낸다 > 프론트에서 아이디 중복검사를 한다 > 통과하면 서버로 요청을 보낸다

프론트에서 할 수 있는 최선은 위와 같다고 생각했다,

1차 중복검사를 통해 서버로 가는 요청을 줄여서 서버의 효율을 높힐 수 있겠지만

결국 서버에서 최종적으로 2차 검증을 해주어야만한다 

효율을 높힐 뿐, 결국 비즈니스로직의 최종 결정은 빽엔드의 역할이다

빽의 모든 역할을 프론트로 위임할 수 없다, 프론트가 뺵의 역할까지 욕심을 내면 안된다

프론트는 빽의 부담을 최대한 들여 빽엔드의 효율을 극대화하는게 최선이다

---

프로젝트를 진행하며 마주한 문제

문제 1 : 서버에서 데이터를 가져올때 발생하는 비효율 문제

내가 진행한 프로젝트는 인터렉션이 자주 일어나고, 인터렉션마다 화면에 최신데이터가 즉각 반영돼야하는 서비스였다

그렇기때문에 2번 고민에서 생각했듯, 인터렉션마다, 변경되지 않은 데이터들까지 포함한 많은 데이터를 계속 가져와야하는 비효율이 있다 

어떻게 해결했나?

캐싱을 이용해 문제를 해결했다, 처음 많은 데이터들을 모두 받아온 뒤, 그 데이터들을 전부 로컬스토리지에 캐싱해둔다

이후 비즈니스로직이 처리되면 비즈니스 로직이 처리된 부분의 데이터만 브라우저로 받아온 뒤, 최신 데이터를 다시 케싱한다, 캐싱된 데이터들을 기반으로 화면을 렌더링 하면, 매번 인터렉션 마다 많은 양의 데이터를 모두 받아올 필요가 없고 인터렉션이 일어나 변경된 데이터만 받아와주면 된다

 

문제 2 : 새로고침으로 인해 발생하는 문제

SPA라서 새로고침하면 가장 처음 화면으로 돌아간다, 모든 화면이 index.html 내부에서 보여지다보니 새로고침을 하면 

처음으로 화면으로 돌아가게된다 

어떻게 해결했나?

화면생성기 함수를 만들었다,

파라미터로 현재 페이지를 받으면 현재 페이지에 맞게 화면을 만들어준다

화면을 만드는 것도 함수로 구현이 돼 있다

 

사용자에게 화면을 변경해주기위해서 

아래와 같은 로직을 사용했다

1. 사용자가 봐야하는 화면의 넘버를 nowPage 라는 이름으로 캐싱한다

2. 화면생성기(캐싱된 nowPage) 를 호출한다 

이게 끝이다

 

화면이 새로고침 되거나, 웹 페이지에 접속하는 경우

 이 코드가 실행이되서 새로고침을 아무리 해도 현재 화면이 유지된다

나머지 코드들은 전부 함수를 구현하는 코드이다, 위 코드가 전부이다

 

 

문제 3 : 실시간 데이터 공유가 이루어지지 않는 문제

게임같이 사용자A로 인해 발생한 비즈니스로직이 사용자B의 화면에도 즉각 반영돼야하는 경우에 문제가있다

내 서비스에는 게임이 들어가있기 때문에 CSR 이든 SSR 이든 상대방이 화면을 새로고침 해주지않으면 다른 사람으로 인해 발생한 비즈니스로직이 즉각 화면에 반영되지 않는다

어떻게 해결했나?

소켓통신을 이용해 해결했다, 이때문에 어쩔 수 없이 SPA의 형태가 무너지게 됐다

---

프로젝트를 진행하며 부족하다고 느낀점 with 학습해야할 것

1. 기획을 제대로 하지못해, 많은 시간을 날렸다 결국 프로젝트를 데드라인 내에 완료하지 못했다

기능을 정의해도 기능을 그냥 계속 바꿧다, 왜? 기능 정의 자체가 제대로 돼 있지 않아서

기능을 바꾸니 당연히 데이터베이스 디자인도 변경된다

MongoDB를 써서 다행이지 rdb를 썻다면 더 많은 시간을 날렸을거다 

기획이 밀리니 모든 일정이 밀린다, 퍼블리싱도 밀리고, 결국 퍼블리싱도 제대로 못했다

>>> 기획에 대해 배우거나 연구하여, 다음 프로젝트에는 기획에서 문제가 발생하지 않게 해야한다

 

2. 데이터베이스를 효율적으로 사용하지못했다

데이터베이스를 제대로 알고있어야 임베딩 방식이건 레퍼런스 방식이건

기능에 맞게 필요에 맞게 데이터베이스를 효율적으로 디자인할 수 있는데

몽고디비를 사용하면서 몽고디비가 가진 장점이나, 언제 사용하면 좋은지 이런것들을 다 모르고

사용했었다, 이걸 알아야 서버에서 브라우저로 전송할 JSON 데이터를 만드는 로직을 최적화 할 수 있는데

그냥 디비에대한 이해도가 낮으니, 디비 디자인을 통한 최적화를 할 수 없었다

>>> MongoDB의 특징과, 사용하는 이유, 장단점, 언제 쓰는게 효율적인지, 데이터베이스 디자인 방법, 디자인 방법에 따른 특징들에 대해 학습하고 연구하여, 다음 프로젝트에는 MongoDB를 활용하여 최적화를 해보는 경험을 가져야겠다

 

3. 작성한 코드의 성능을 측정할줄 모른다 

측정을 할수 있어야 개선을 할 수가 있는데, 지금 내가쓰는 코드의 성능을 제대로 측정할줄 모른다

우선 서버에서 처리되는 로직이 어떤 순서로 어떤 일들을 처리하는지에 대해서 대충은 알지만

특정 일을 처리하는데 얼마나 시간이 걸리는지, 얼마나 자원을 사용하는지를 잘 모른다

그래서  측정도 개선도 하지 못한다, 그래서 알고리즘을 이용한 최적화를 할 수 없다

>>> 서버에서 처리되는 로직이 어떤 순서로 어떤 일들을 처리하는지 제대로 알고, 사용되는 코드들이 얼마의 시간과 얼마의 자원을 사용하는지 제대로 알아보고, 문서화해두어, 다음 프로젝트에서는 알고리즘을 활용하여 최적화를 해보는 경험을 가져야겠다