Pushpin: 브라우저 지원

아, 저는 브라우저 지원에 찬성합니다! 브라우저에서 프론트엔드를 실행하고 노드 프로세스에서 백엔드를 실행할 수 있다고 생각합니다.

즉, 프론트엔드는 렌더 스레드일 뿐입니다. 실제로 흥미로운 일을 하려면 항상 프론트 엔드와 함께 백엔드가 있어야 합니다. 나는 우리가 당신이 Gozala를 찾고 있는 것에 더 가깝고 공유 백엔드에 더 많은 책임을 아웃소싱하는 ... 미드엔드를 상상할 수 있다고 생각합니다.

즉, 이 프로젝트에 대한 명시적(그러나 변경 가능한) 엔지니어링 목표는 자체 포함됩니다. 작업을 수행하는 데 외부 서비스가 필요하지 않습니다. 설치하거나 의존할 다른 것이 없습니다.

구체적으로 백엔드에 대해 생각하고 있는 것은 네트워킹 및 파일 시스템 기능을 제공하는 부분입니다. 이상적으로는 백엔드가 다운된 경우 프론트엔드 캐시에서 변경 사항을 유지할 수 있어야 합니다.

로컬/오프라인 변경 사항이 프론트 엔드에서 유지되지 않고 사용 가능하게 되면 백엔드로 복제될 수 없는 이유가 있습니까? 그것은 분명히 구현 복잡성과 다릅니다.

글쎄요, 지속하는 것은 백엔드의 일입니다. 그것이 내가 말하려는 것입니다. 프런트 엔드는 지속되지 않는 단일 렌더 스레드입니다. 이것은 프런트 엔드의 중요하고 필수적인 속성입니다. 로컬 지속을 수행하고 백엔드 없이 작동할 수 있는 일종의 미드엔드를 갖고 싶다면 전체 피어로 만들지 않겠습니까?

프론트 엔드가 지속성을 수행하지 않는 이유는 지속성, CRDT 계산 및 그 모든 것이 입력 스레드를 차단하기 때문입니다.

글쎄요, 지속하는 것은 백엔드의 일입니다. 그것이 내가 말하려는 것입니다. 프런트 엔드는 지속되지 않는 단일 렌더 스레드입니다. 이것은 프런트 엔드의 중요하고 필수적인 속성입니다. 로컬 지속을 수행하고 백엔드 없이 작동할 수 있는 일종의 미드엔드를 갖고 싶다면 전체 피어로 만들지 않겠습니까?

알겠습니다. 중간 용어를 채택하겠습니다. 그러나 이 맥락에서 "전체 피어"가 무엇을 의미하는지 완전히 확신할 수 없습니다.

프론트 엔드가 지속성을 수행하지 않는 이유는 지속성, CRDT 계산 및 그 모든 것이 입력 스레드를 차단하기 때문입니다.

브라우저에는 꽤 오랫동안 작업자 스레드가 있었습니다. 실제로 서비스 워커와 함께 이러한 종류의 작업에 적합합니다. 완전히 그리드에 있고 백엔드 프로세스가 범위를 벗어나면서 모든 것을 실행할 수도 있습니다.

예, "백그라운드" 작업자를 서비스 작업자로 이동하고 압정이 PWA로 작동하도록 하고 싶습니다. 그게 꿈이야!

작업자의 경우 몇 가지 중요한 주의 사항이 있지만 내장 IndexDB 또는 유사한 "브라우저 기본" 스토리지 솔루션과 같은 것을 사용하여 브라우저에서 장기간 지속성을 수행할 수 있습니다. 현재 이 작업을 하고 있는 사람이 있습니까?