I am trying to find information on best practices for json data. I am working on a client server app that will contain family information. For purposed of this question, this is an oversimplification of the database. I have a family table, an address table, and a family members table. There are also a number of other tables that contain email addresses, phone numbers, etc. For each family, there can be multiple addresses (for the old folks that fly south for the winter), and multiple family members and each family member can have multiple phone numbers and email addresses. The family UID is in each table to enable linking. To retrieve all information for a family, should I build a complex JSON string that contains all of the data that needs to be parsed out manually or should it be individual calls, 1 for the family details, 1 for the addresses, 1 for the family members, 1 for each family members email addresses, and 1 for each family member's phone numbers? The single call seems very complicated but the alternative seems like a lot of overhead with connections, etc.

Dani AI

Generated

Two practical API patterns work well together; pick the one that matches the use case.

For bulk operations like printing a report (your scenario, ) return a server-side "bundle" — a single endpoint that assembles a consistent snapshot of family, addresses, members, phones, emails, etc., in one response. That avoids many round trips, guarantees atomic consistency, and lets the server optimize the database access (single query with joins or ORM eager-loading), compression, and streaming if the payload is large. For interactive screens follow ’s idea: fetch only what the UI needs and request details on demand.

Design tips and tradeoffs

  • Provide a flexible single-call option: support query params such as ?include=addresses,members,emails,phones and ?fields[...] so a client can request a single, tailored payload when needed.
  • Avoid duplicating the same data in many places; either normalize with top-level maps (addresses keyed by id) or use an "included" section to list shared objects once. That saves bandwidth and parsing work.
  • Use server-side eager loading (JOINs / ORM joinedload) to prevent N+1 queries, enable gzip compression, and add ETag/If-None-Match for caching. For very large exports consider streaming NDJSON so the client can process rows incrementally.
  • Be mindful of client memory and mobile networks: even a single large JSON can be slow or crash low-memory clients — allow chunked downloads or an export file format (CSV/JSON file) for very large reports.

Quick Python sketch (conceptual)

# Flask + SQLAlchemy (conceptual)
from flask import jsonify
from sqlalchemy.orm import joinedload

@app.route('/families/<int:fid>/bundle')
def family_bundle(fid):
    family = (db.session.query(Family)
              .options(
                  joinedload(Family.addresses),
                  joinedload(Family.members).joinedload(Member.emails),
                  joinedload(Family.members).joinedload(Member.phones)
              )
              .filter(Family.id==fid).one_or_none())
    return (jsonify(FamilySchema().dump(family)), 200) if family else (jsonify({'error':'not found'}), 404)

Recommendation: implement a bundle/export endpoint for reports, and the lean include/fields pattern plus caching for interactive UI.

Recommended Answers

All 3 Replies

There's no magic to be done. You should load at first what you'll display right on to your users, details can be loaded latter.
Example: If your home screen is just the family members names, there's no need to load all the data at once.
If you need to click on a button to see the phone numbers, the phones can be loaded alone.
It's all about finding the best cost/benefit for your app.

Let me ask that differently. If I need all of the data at the same time (printing a report for example), for each family, should I create the complicated single JSON string or create multiple JSON strings?

It's easier if you get all the data in a single json but the band consumption is lower if you don't load the same data twice.
If some data(one address for example) is the same for various records(family members in this case) you can get it as a stand alone json and them link them with the family menbers on yout UI.
This way the bandwith consumption will be lower but the processor consumption will be higher.
I'd take apart the data if yours users have decent machine and browsers.
I say so because I once tried to do a rich UI with JS on a project that was used by old pcs on IE 7. Guess what? It crashed a lot. In that case more bandwith consumption and less processor was the key to success.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.