General question about “best practices” — we can store lots of data in Page Data, which is super great… but this has to be stored in the page on the users browser somehow.
I’m curious: how much is too much when it comes to Page Data? I’m guessing that having 50 Mb of Page Data would cause some issues with Browser memory, especially if the browser/device is old. Any thoughts/insights from anyone are much appreciated 
Page Data is the data model for the entire page. It is recommended to fraction your entire page into “work zones”, where each zone gets its own data model. This will result in a significantly better-performing UI. See the following documentation page for more details:
https://backendless.com/docs/uibuilder/ui_data_models.html
While it may be convenient to put everything into Page Data, the side effect of that design decision is that everything on the page will be re-rendered when the Page Data storage changes (which is not a good thing).
Hope this helps.
Mark
Yes, understood — and we do make extensive use of the “data container” check box on blocks 
.
But we have a page where lots of things all depend on an array of objects which we keep in Page Data. These objects are small (~5 little strings), but I’m wondering if it’s kosher to build things this way for the (very rare) case that a user will get 1,000 such objects in their array. We will test things of course with a big load of dummy data… but I thought perhaps there is a general guidance about Page Data limitations.
Your statement also leads me to another question: if Page Data has 2 properties A & B, and on the page are two components X & Y which get their data from A & B respectively… you’re not implying that if A is modified, Y is re-rendered, or?
Yes, Y will be re-rendered in that case.
Btw, 1000 objects in the UI model might be a clue that the UI needs some refactoring. If these objects are actually displayed somewhere on the page, it could indicate that the UI is too busy (for the end-user). If the objects are used for calculation, it might be better to shift the logic to the server. These are general guidelines, however, every project is different and it might make perfect sense with what you’re doing.
Regards,
Mark