tiblu
commented
5 years ago Why the sync?
- Loading Etherpad for every view is very slow, even in read-only mode, so when integrating the editor, we decided to load the Etherpad only when in "edit" mode to provide better user experience, specially with slow connections.
- There are views, where the full document is not shown, but parts of it - only the title for example. We need the updated title which is parsed from the Etherpad content on sync.
- Etherpad is a separate application with it's own database and server. We want to keep the loose coupling and not touch Etherpad internals from Citizen OS code directly.
- It's very important that when a vote is started, the latest version has been synced from EP and it never changes in the DB - everybody votes the same content.
The current sync
After code review , @ilmartyrk found that Citizen OS API does the sync with revision number, which causes the Etherpad (EP) API to fall into expensive revision fetch and apply logic. We're changing it to call it without revision, which falls into much cheaper logic on the Etherpad side.
Future of the sync?
- We MAY want to contribute to making Etherpad read-only view loading faster, because in the future the read-only view of the Topic should show all the inline comments and inline votes etc which all are integrated into Etherpad. Sync becomes less important if we load the full EP read-only view with latest info from EP database.
- The sync MAY still remain as we have less places and less info to show in the views that do not show the full document. Mostly we only need the title for the dashboard,
/homestill uses the full document text tho, but if that is a bit out of sync, that's not a big deal. - When we start having performance issues with the sync, we will increase the
ep_webhookdebounce parameter thus syncing with a bigger interval. While the read-only views will be a bit out of date, it goes a long way in terms of performance gains.
KatiVellak
loorm
Related issues: