I'm aware of @pvh's skepticism towards browser support, however I still think separation of backend / frontent concerns might be good move. What I mean specifically is it would would be really nice if I could load pushpin UI in my browser as a tab. That way it could talk to the backend on my machine or talk to the one in my closet.
I would like it even better if it worked in (limited capacity) even if backend is out of range. As of electron it would just mean that front end happens to be loaded in the renderer process while backend is loaded in the background process.
Is this too crazy ? or too much work ? Or maybe there are specific limitations that would be hard to impossible to overcome ?
I just want to kick around this idea, mostly because I find upfront costs of installing an electron app to high in comparison to trying it out in the browser and installing app for convenience.
Gozala
All 9 comments
Oh, I'm all for browser support! I think we could run the front-end in the browser and the back-end in a node process.
pvh
on 6 Nov 2019
That said -- the front-end is just a render thread. You need to have a back-end present with a front-end at all times to actually do anything interesting. I think we could imagine a ... mid-end which would be closer to what you're looking for Gozala and outsource more responsibility to a shared back-end.
That said, it is an explicit (but possibly changeable) engineering goal for this project that it is self-contained. No external services are required for it to do is work. Nothing else to install or rely on.
pvh
on 6 Nov 2019
To be specific what I'm thinking of backend is pieces that provide networking & filesystem capabilities. Ideally fronted should be able to persist changes in the frontend cache if backend is down.
Are there any reason why local / offline changes could not be persisted in front end and replicated to backend once it's available ? That is other than implementation complexity obviously.
Gozala
on 6 Nov 2019
Well, persisting things is the job of the backend. That's what I'm trying to say. The front-end is a single render thread that does no persisting. This is an important and essential property of the front-end. If you wanted to have a sort of mid-end that did local persisting and could operate without the back-end then why not make it a full peer?
pvh
on 6 Nov 2019
The reason the front-end doesn't do any persisting is because persisting, CRDT calculation, and all that stuff blocks the input thread.
pvh
on 6 Nov 2019
Well, persisting things is the job of the backend. That's what I'm trying to say. The front-end is a single render thread that does no persisting. This is an important and essential property of the front-end. If you wanted to have a sort of mid-end that did local persisting and could operate without the back-end then why not make it a full peer?
Alright, I'm willing to adopt mid-end terminology. However I'm not entirely sure what "full peer" means in this context.
Gozala
on 6 Nov 2019
The reason the front-end doesn't do any persisting is because persisting, CRDT calculation, and all that stuff blocks the input thread.
Browsers had worker threads for quite some time now. They are good fit for this kind of stuff in fact with service workers you could even run the whole things while being totally of the grid and with back-end process out of range.
Gozala
on 6 Nov 2019
Yea, I'd love to move the "background" worker into a service worker and make pushpin work as a PWA. That's the dream!
pvh
on 6 Nov 2019
For the worker, you can do longer term persistence in the browser with something like the builtin IndexDB or similar "browser native" storage solutions, although there are some important caveats. Is anyone working on this currently?
mscottnelson
on 11 Jul 2020
Related issues
pvh
·
4Comments
canadaduane
·
9Comments
Gozala
·
4Comments
Gozala
·
13Comments
radio-alice
·
7Comments
Most helpful comment
Yea, I'd love to move the "background" worker into a service worker and make pushpin work as a PWA. That's the dream!