I've spent a lot of time working with older web technologies like hand-crafted HTML and CSS, and spent over 20 years running a WordPress site. Recently, I've built applications using Django, Flask, and FastAPI, primarily using Jinja templates. My focus has mostly been on traditional interactions, where you click and a new page loads. But now, I'm looking into using Pyscript to add interactivity while avoiding the complexities of JavaScript.
I'm specifically curious about how often I should poll for fresh, authoritative data in my web apps. For example, I'm working with Taskwarrior, a command-line task management app, and I'm using an API library to retrieve my tasks and their details. My plan is to call the API to get all tasks when the page loads, which provides me with a JSON response that I can manipulate.
When a task is completed, I'd like to remove it from the display. Should I delete it from my Pyscript dictionary as soon as I send the command to mark it completed, or should I wait for the API to confirm the task's deletion? If I wait for the confirmation, does that mean I should also re-fetch the updated list of tasks?
3 Answers
Overall, how often you need to refresh your data depends on how critical it is to have it up-to-date. If the data changes frequently or multiple users are accessing it, it makes sense to refresh after important actions. For static data, longer caching might be acceptable. Personally, I lean toward refreshing after write actions and keeping short intervals for read operations.
This question touches on the broader topic of distributed system design, and the answer is often 'it depends'. Ideally, if both your client and server understand and apply changes the same way, they’ll end up with matching states. However, complications arise with concurrent edits and processing orders. You may want to consider whether you need to re-fetch data based on your app complexity. If it’s just you using the app and you’re okay with potentially seeing stale data, cutting out re-fetching might be fine. Alternatively, you could implement something like event sourcing to keep track of changes.
That's a good point! But aren’t web sockets similar to rapid polling in practice? My server has two containers: one for the web app and another container syncing with the taskwarrior. It syncs changes every minute, mostly I use one or the other.
Yes, you should wait for the 200 OK response before assuming the task was deleted. It's always a good idea to give users feedback, like graying out the task or showing a spinner, to indicate that their delete request is being processed. As for whether you need to re-fetch the JSON data, that depends on the reliability of your backend. If it's simple and reliable, you might just be okay deleting it from the front end after getting the confirmation. But if there’s any complexity, I'd definitely recommend fetching the updated data again.
Thanks for the insight! In my case, it's just one user and the sync server should keep everything up-to-date, so I might not need a spinner after all. But I’m thinking of sending a payload back with the 200 OK to help confirm the action, that way I can ensure everything matches.
Great insight on the balance! Definitely will keep that in mind.