Skip to content

Latest commit

 

History

History
18 lines (13 loc) · 2.43 KB

data-persistence.md

File metadata and controls

18 lines (13 loc) · 2.43 KB

Data Persistence:

LocalStorage or IndexedDB

  1. LocalStorage is great for small amounts of data and is very simple to use. !LocalStorage is synchronous, meaning it can block the main thread, leading to performance issues.
  2. IndexedDB is more complex, but it's much more powerful and is the recommended solution for larger or more complex data needs. !IndexedDB is asynchronous and non-blocking.

There are a couple of strategies to keep your local storage in sync with the server data:

  1. Polling: Regularly fetch the data from the server and update the local storage. How often you should fetch the data depends on your application and how quickly the data changes. This is a simple but potentially resource-intensive solution, especially if the data doesn't change very often.

    1. Once you have fetched the data from the server using polling, you can sync it with local storage. You can do this by storing the data in the local storage after processing it. !You need to consider the case where a user might reload or close the page during the polling interval

  2. Websockets / Server-Sent Events: If your server supports it, you can use WebSockets or Server-Sent Events to push updates to the client whenever the data changes. This is a more complex but efficient solution, as it minimizes unnecessary data transfers.

  3. Versioning / ETags: If your server supports it, you can include a version number or an ETag with each piece of data. Whenever you fetch the data, you can compare the version number or ETag with the version you have in local storage. If the versions don't match, you can update the local storage.

    1. To check if ETags are supported: curl -I http://<your-server.com/some-endpoint> => ETag: "some-value"
    2. Versioning curl -I -H "Accept-Version: v1" http://your-server.com/some-endpoint => the response should reflect the version you requested in the headers

  4. Last-Modified Header: If your server supports it, you can use the Last-Modified HTTP header to determine when the data was last changed. Whenever you fetch the data, you can compare the Last-Modified date with the date you have in local storage. If the server's date is more recent, you can update the local storage.

    1. The Last-Modified header value can be retrieved from the Response object returned by the fetch API in JavaScript. response.headers.get('Last-Modified');. Server responds with a 304 Not Modified status if the resource hasn't changed since the client's last request.