API for activity page

[wbazant]

Missing data - see falling-fruit/falling-fruit-web#537 (comment) . Maybe there's a join to the users table that should be a left join?

Also, address is sometimes missing - maybe the payload could include coordinates, and then we'd render that instead.

Also: @paskal98 suggests to modify the API for /locations/changes to include the ability to search by date parameters “start” and “end". Makes sense to me - with "offset", if someone adds a change just as we query, won't it mess up the data?

[ezwelty]

Missing data - see falling-fruit/falling-fruit-web#537 (comment) . Maybe there's a join to the users table that should be a left join?

Yikes, a silly bug but an easy fix. Thanks @paskal98 for discovering and report it.

Also, address is sometimes missing - maybe the payload could include coordinates, and then we'd render that instead.

Good idea, I included location lat, lng to the response.

Also: @paskal98 suggests to modify the API for /locations/changes to include the ability to search by date parameters “start” and “end". Makes sense to me - with "offset", if someone adds a change just as we query, won't it mess up the data?

Hmm, also a good point. (Although wouldn't this always be a potential issue with paginated searches?) I could drop limit and offset and use two dates and allow the most recent date to be null so that the search interval goes up to the present?

[wbazant]

(Although wouldn't this always be a potential issue with paginated searches?)
I agree! I suppose we could catch it in e.g. list-locations - we'd know, because we would see a location twice - it's super unlikely and not a severe bug. It's also not a severe issue here, although probably the likeliest of them all - anyone adding or editing a location will trigger it. I withdraw that part!

Some other benefits I can see: if you use dates instead of limit and offset, it supports a query interface (although we don't really need one), also, that the responses could be cached (but deleting a reported location should invalidate the cache). I think the biggest reason is that it simplifies the frontend code a bit, since it's nice to show complete days of changes, and with limit and offset, we can never be sure we got all the data for the last day.

[ezwelty]

Live API now provides earliest (inclusive, i.e. date >=) and latest (exclusive, i.e. date <) query params. These are ISO 8601 UTC timestamps (e.g. '2024-11-09T13:54:48.895Z') so that you can even paginate in n-day chunks in an arbitrary timezone.