Conversation
* Add, edit, delete, get (by list id, user id) location lists * Reordering locations is not currently supported (maintains locations_routes.position but no endpoint to change it) * Only private lists are currently supported (ignores routes.is_public) Closes #8
|
Thanks, I think that will work for the UI! It didn't seem useful to let users customise ordering of locations or lists, the public routes are interesting for one day if we see people invested in their Falling Fruit profiles or if they want to share lists? For GET /locations including in_list, you're right that it is a lot of in_list: false being returned, it's also the heaviest table, could even one day be moved out into indexed search for extra good searching. I can also be querying for the lists on start-up, or we could add a list of saved location ids to the user payload for one less API call. Having in_list on GET /locations payload has a benefit of the data being fresh - if the user opens their app, and then saves a location on their desktop, the app will still show the location as saved after moving the map. Not sure how much it matters, I thought of it because we also have the 'recent activity' data not updating on the app - falling-fruit/falling-fruit-web#1007 . |
|
@wbazant The So if you think the current implementation is the best/easiest way to keep the map up to date with location lists, then we can go with what I already have? (and iterate later if needed) Otherwise, good alternatives would be to query |
|
Happy to go with the current version, that would be easiest for the ui too, and we can change it if needed one day. |
Preview docs: https://petstore.swagger.io/?url=https://raw.githubusercontent.com/falling-fruit/api/location-lists/docs/openapi.yml
locations_routes.positionis maintained, but no endpoint is (yet?) provided to reorder locations.routes.is_publicis ignored.GET /locationsandGET /locations/:idnow support authentication, in which case the former returnsin_list: booleanfor each location and the latter returnslists(array of Location Lists). I was worried the former would add a high overhead but I didn't notice any significant performance hit in my scant testing. But I have to wonder – does it make sense to return thousands of booleans when we could just have a small array of location ids?Closes #8