React를 사용한 후에는 데이터에서 View를 렌더링하는 과정이 비교적 쉽습니다.
하지만 보다 실용적인 애플리케이션에는 서버 지원, 다중 사용자, 실시간 동기화 등이 필요합니다.
기존 실무에서 몇 가지 문제에 직면했습니다(저는 백엔드 아키텍처에 대해 잘 알지 못하기 때문에 프런트엔드 관점에서 봅니다):
브라우저 측에서 데이터를 캐싱할 때 때로는 외부 데이터가 서버에서만 캡처될 수 있습니다.
서버는 브라우저에 필요한 데이터가 무엇인지 항상 알 수는 없습니다
브라우저에는 수동으로 유지 관리하고 서버 등으로 업데이트해야 하는 데이터 백업이 있습니다.
서버가 데이터를 푸시할 때도 유사한 작업이 수행되므로 양쪽에 중복 코드가 있을 것입니다
그래서 저는 전체 프로세스를 더 명확하고 단순하게 만드는 솔루션을 생각하고 있습니다(소형 애플리케이션의 경우 성능이 먼저 고려되지 않음):
데이터 작업은 브라우저 측에서 수행되며 모든 변경 사항은 서버에서 푸시된 데이터를 기반으로 이루어집니다.
즉, 서버에는 사용자가 필요로 하는 완전한 데이터가 있고 브라우저는 수동적으로만 동기화됩니다
서버는 브라우저가 어느 테이블로 이동하는지 등 각 사용자의 현재 상태를 모두 저장합니다.
이런 방식으로 서버는 현재 사용자에게 필요한 모든 데이터를 계산할 수 있습니다
클라이언트의 데이터 관련 작업은 모두 WebSocket을 통해 서버로 전송되고 서버에서 처리됩니다.
서버는 jsonpatch 및 WebSocket
저는 이 아이디어를 오랫동안 생각해 왔지만 아직 깊이 생각해 본 적이 없습니다. 그런 계획을 생각해 본 반 친구들이 있나요?
또한 제가 고려하고 있는 시나리오는 수십 명의 사람들이 동시에 온라인에 접속하는 소규모 애플리케이션이라는 점에 유의하세요...
滿天的星座2017-05-16 17:08:28
이것을 정답으로 생각해서는 안 됩니다. 그냥 함께 토론해 봅시다. 설명하신 내용 중 일부를 이해하지 못하는 것 같으니 먼저 서로 같은 생각인지 확인하도록 하겠습니다.
브라우저가 데이터를 캐시할 때 때때로 외부 데이터는 서버에서만 캡처할 수 있으며, 서버는 브라우저에 필요한 데이터가 무엇인지 항상 알 수 없습니다
잠깐만, 서버에서 데이터를 가져올 때 요청 유형을 선언해야 하지 않나요? 서버는 왜 브라우저에 필요한 데이터가 무엇인지 "알아야" 합니까? 즉, 캐시된 데이터에 "작성자 정보"가 누락되었다고 가정하면 GET /author/:id가 되어야 겠죠? 이것이 브라우저에 필요한 데이터가 무엇인지 서버가 "항상 알 수는 없다"는 것을 어떻게 의미합니까? 무슨 뜻인지 명확히 하기 위해 예를 들어주실 수 있나요? GET /author/:id 对吗？这样怎么会变成服务器“并不总是知道”浏览器需要什么数据？能否举一个例子说清楚你的意思？
浏览器有一份数据备份, 就需要手动维护, 保持跟服务器更新等等、而类似操作在服务器推送数据时也会做, 这样两边就有重复代码
我觉得“推送”就意味着：浏览器其实不知道数据有更新，服务器知道，所以服务器推给浏览器更新后的数据。而你在浏览器手动维护的数据则意味着：你知道数据变化了，所以才要手动维护，并且要提交给服务器以同步数据。
你不觉得这两者恰好是一条线的两端，其实不矛盾吗？为什么会有重复代码？你指的是用于同步数据的代码？
所以你所思考的方案：
浏览器端进行数据的操作, 全部靠服务器推送的数据进行更改
意思是客户端不做数据缓存？只要有数据变更操作就从服务器即时获取完整的数据（或者说，一个用户做了操作就立刻把数据更新推给其他所有的客户端）？
……哪个表的哪个数据
若我没理解错，你的意思是假设我是用户 A，我正在看/author/5的资料，服务器上应该有一个游标机制注明：“用户 A 正在浏览 authors 表 id 为 5 的数据”，是吗？换句话说，每当 URL 改变的时候就应该发送给服务器“我当前的位置”，然后服务器就把相应的数据推送给我，是这个意思？
那……这和我直接 GET /author/5
🎜내 생각에 "푸시"는 데이터가 업데이트되었다는 사실을 브라우저가 실제로 모르고 서버가 알고 있으므로 서버가 업데이트된 데이터를 브라우저에 푸시한다는 뜻이라고 생각합니다. 브라우저에서 수동으로 유지 관리하는 데이터는 데이터가 변경되었음을 알고 있으므로 수동으로 유지 관리하고 데이터를 동기화하기 위해 서버에 제출해야 함을 의미합니다. 🎜 🎜 이 둘이 정확히 같은 선의 두 끝이고 모순되지 않는다고 생각하지 않나요? 왜 중복된 코드가 있나요? 데이터를 동기화하는 데 사용되는 코드를 말씀하시는 건가요? 🎜 🎜 🎜그래서 당신이 생각하고 있는 해결책은: 🎜 🎜 🎜데이터 작업은 브라우저 측에서 수행되며 모든 변경 사항은 서버에서 푸시된 데이터를 기반으로 이루어집니다.
/author/5의 정보를 보고 있다고 가정하면 서버에 다음을 나타내는 커서 메커니즘이 있어야 한다는 의미입니다. "사용자 A id가 5인 작성자 테이블을 검색하고 있는 거죠? 즉, URL이 변경될 때마다 "내 현재 위치"를 서버로 전송해야 하며, 그러면 서버가 해당 데이터를 나에게 푸시한다는 뜻인가요? 🎜
🎜
🎜그렇다면...이것과 내가 GET /author/5를 통해 직접 데이터를 얻는 것의 차이는 얼마나 됩니까? 🎜
🎜
🎜설명하신 내용에 대해서는 각자의 생각이 있는 것은 알겠습니다만 아직 장면이 너무 모호한 것 같습니다. 구체적인 시나리오를 예로 들어 어떤 문제가 해결됐는지 좀 더 구체적으로 듣고 싶습니다. 🎜淡淡烟草味2017-05-16 17:08:28
그리고 서버는 브라우저에 어떤 데이터가 필요한지 항상 알 수는 없습니다
서버와 브라우저 간의 통신은 사양을 기반으로 해야 합니다. 애플리케이션 개발에서는 백엔드와 폰트엔드 간의 통신이 매우 중요합니다
브라우저에는 수동 유지 관리, 서버 업데이트 유지 등이 필요한 데이터 백업이 있습니다.
실제로 비즈니스 데이터는 결국 서버에 저장되어야 하고, 데이터베이스(mysql 등)가 그러한 서비스를 제공합니다. 데이터는 서버와 클라이언트 사이에서 상호 작용합니다. 간단히 말하면 브라우저의 데이터를 캐시라고 할 수 있습니다. 캐시 범위가 매우 넓고 last_modified 및 etag도 캐시 중 하나일 뿐만 아니라 서버 애플리케이션 내부의 캐시이기도 합니다
반복되는 코드의 경우 실제로는 백엔드와 폰트엔드 간의 업무 분담이 불분명하고 기술적인 아키텍처 때문에 발생하는 것일 수도 있습니다. 그러나 때로는 프로젝트를 빠르게 시작하기 위해 코드 복제를 허용하는 경우도 있습니다. 나중에 천천히 재구성할 수 있습니다. 초기 단계에서는 현재의 기술 수준에 따라서만 선택할 수 있으며, 기술에 너무 깊이 빠져들면 프로젝트가 일정대로 완료되지 않을 수 있습니다
데이터 작업은 브라우저 측에서 수행되며 모든 변경 사항은 서버에서 푸시된 데이터를 기반으로 이루어집니다
즉, 서버에는 사용자에게 필요한 완전한 데이터가 있고 브라우저는 수동적으로만 동기화합니다
애플리케이션은 다 이와 같고, 데이터는 결국 서버에 도착하게 됩니다.
서버는 브라우저가 어느 테이블로 이동하는지 등 각 사용자의 현재 상태를 모두 저장합니다.
이런 방식으로 서버는 현재 사용자에게 필요한 모든 데이터를 계산할 수 있습니다
일반적으로 서버는 무상태로 설계됩니다. 이는 향후 프로젝트가 개발될 때 서버 확장이 필요할 것입니다. 브라우저에 데이터가 필요할 때 서버로 가서 데이터를 얻습니다. 서버는 브라우저가 보낸 매개변수와 인터페이스 프로토콜에 따라 데이터를 제공하며, 브라우저는 현재 사용자가 어떤 테이블과 위치에 있는지 쉽게 알 수 있습니다. 예를 들어, Sina Weibo 웹사이트는 특정 양에 도달하면 서버에서 데이터를 가져오는 데 앞장서며 다음 페이지의 데이터를 가져오기 위해 다음 페이지의 링크를 사용합니다.
클라이언트의 데이터 관련 작업은 모두 WebSocket을 통해 서버로 전송되고 서버에서 처리됩니다.
을 통해 로컬 데이터 백업을 업데이트합니다.
서버는 jsonpatch 및 WebSocket
이 기술의 구현은 주로 애플리케이션 시나리오와 관련이 있습니다. Websocket은 데이터를 얻기 위한 긴 연결에 적합합니다. 일반적으로 데이터를 업데이트하는 경우 일반 http 프로토콜을 사용하면 충분합니다.