On Sunday 11 June 2017 14:41:22 Miika Huusko wrote: > The reason I'm providing all "Items" and other relates stuff with one > request is that I want to make customer (that's also me and my good > frieds) life easier. I want to keep all the difficult and heavy work > on server side. Customer needs all data because of offline > requirements and therefore would need to loop through pagination or > perform the same big JOIN if "Photos" and other related objects would > be requested separately. Doing that in mobile devices is going to > take longer than on Ubuntu server even if it takes longer that I > would expect with Python + Django. That said, it's good to point out > opinions on design patterns. I haven't listed all background > information for decisions.
Think about how Google Maps does this with Offline dataset for area's you've marked. They cache it for x days. Then prompt you if you have a free moment to sync up till you do. It's not a burdon in practice and makes life a lot easier. Sometimes we set requirements too harsh for ourselves. > I'm not quite sure what you mean by "hash photos and use that as > identifier". Sorry, I wasn't complete as it's been a while. I've built an application that fetches Zendesk data into Django to for trend analysis. To get an attachment, for a given message was: - get the message id: /messages/id - get the attachment id's: messages/id/attachments (this is your reverse related) - for each one that you don't have yet, fetch it: /files/id The hashing came into play, because corporate idiots - I mean people - attach their logo to each and every email they send. So by hashing them, you eliminate duplicates and scale down your storage requirements and (query) data size. > What I could do - and believe what you mean(?) - is to > provide list of "Photo" IDs (or hashes) for "Item" and ask customer > to fetch "Photo" details separately with another request(s). Or - > easier for API - leave "Photo" IDs out of the "Item" information > completely and ask customer to make the JOIN with separately > requested "Photos". JOIN could be done with hashes or IDs. Either way > it would be customer who would make the JOIN. But it makes a lot more sense now with the mobile and offline requirements, why you have setup the API the way you did. Two more thourghts for you: - Use a cacheable dataset and incremental updates to be done "when wifi or better is available". Complex, but worth it in the long run. - Ditch DRF serialization and get the querieset as values(), dumping to json instantly and thus eliminate both serialization objects and model objects. It's easy to test the performance gain of the 2nd, especially if you can stream the json (as opposed to in-memory-then-flush). -- Melvyn Sopacua -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1751373.LEcVXiJZ3g%40devstation. For more options, visit https://groups.google.com/d/optout.
