@톨머프
일단 글에서 데이터 로직이 복잡해 지고, 관리해야 하는 플러그인이 늘어난다는 것이 개발자의 부담을 늘리게 되어서 Redux를 GraphQL 기반의 Platform인 Apollo로 대체했다고 되어 있습니다.
여기서 제가 동의할 수 없거나, 글에서 주장의 동기가 부족한 이유이긴 합니다. Redux의 단점으로 Bolierplate때문에 Verbose하다는 것은 이미 많이 알려진 이야기 입니다.
단점이 되기도 하지만, 장점으로 예측 가능하거나, 테스트/디버깅 하기 쉽거나, 확장성이 용이하기 위한 패턴이긴 합니다. 그래서 Redux가 좀 더 복잡한 로직을 처리하기가 유용할 수 있고, Apollo가 그 문제를 해결해 주지는 않습니다.
태생적으로 Apollo가 가진 Cache가 상태를 관리해주기 위한 패턴으로 개발된 것이 아니고, 그걸 대체한다는 표현을 쓰는 것 까지는 무리가 있다는 것이 제 생각입니다.
아얘 처음부터 생산성에 초점을 쓴 글이면 동의를 할 수 있겠으나, 다른 여러 Tech stack들이 혼합 되면서 왜 선택한지에 대한 의문이 더 늘어가게 됩니다.