Efficient saving of editor content in the database

[NiclasDev63]

Hi,

I am currently implementing the backend to save the editor content. However, the question arises as to the best way to do this. Currently I send the complete editor content as JSON to my backend after each keystroke (with debounce) and store it in my DB, which is obviously very expensive for large documents. Is there a more efficient way to do this? I know that Notion stores each block individually and so only needs to send the diffs to the backend and only updates individual blocks, but they use a different scheme where each block has a pointer to its parent and its content, which is not the case with Tiptap. Is there a way to update the data in a similarly efficient way without having to change the complete schema of Tiptap?

I would be grateful for any suggestions.

Thanks

[nperez0111]

Hi @NiclasDev63

There are a couple of different solutions for saving back editor content from a Tiptap editor:

• Depending on your user experience, you can have the user confirm that they want to save the content to your system (like a save button) so that you incur this storage performance only once
• If you want to use auto-saving, you can do it with a debounced on change handler that will only save it after some amount of time has passed since the latest change

Converting editor content into JSON is not an expensive process, and for the size of documents that users typically write, the size of documents are typically negligible (measured in KBs), so I would not be so concerned about it until you actually run into the performance issue which I doubt you have.

If you really do need the performance, then you can go ahead and build some sort of diffing system that would be able to take the parts of the document that changed and only send those as updates to the current document. This is obviously a much more complex system to manage so I really would not recommend it unless you see real performance problems over the wire.

[NiclasDev63]

First of all, thanks for the quick reply.
Auto-saving should be used in any case and as described, I already use a debounced on change handler, but after each change (and a short waiting time) the whole document, which can easily have 500KB-1MB+, is sent. Since this can quickly happen 100+ times within a short period of time, I thought it wouldn't hurt to look around for a more efficient variant, but then I'll stick with my current variant for now.