Hi Grist,
I’m writing this as a feature request with a rather long-winded explanation for why I would like to have it. I know you are all very busy building this amazing product, so I don’t expect an answer anytime soon. Just a suggestion that would help me and maybe others. Please receive it with my gratitude and all possible humility.
I have a free public-facing educational website that uses Grist as the database, a freely hosted React app as the frontend (proof of concept demo for now), and napkin.io as a midpoint for API calls. Napkin has a payload size limit, which means that I can’t request an entire table of 1000 rows with 5 fields at once. But the site needs to be organized around a list of hieroglyphic signs, which totals about 1300 rows. In the same row as each hieroglyphic sign there are also foreign id’s that link to other open-data projects, such as the Thot Sign List, etc. Plus there are fields with descriptions of the glyphs, citations to academic sources, etc. Having all that info together means I can’t get the main sign list as the backbone of the website without pulling all that other data, even though I don’t actually need it in to main overview. Even if I did that, Napkin’s payload limit would throw an error.
My current solution is to make one table for the sign list with only a single field (smaller than the transfer limit), pull all of that into the app, and then use the filter feature of the Grist API to grab the additional information from an identically-sized table with more fields, such as the id’s for other project entries, descriptions of the signs, etc. This seems like an ok solution, but a more elegant one would be to make a Grist API call requesting specific fields. Then I could put all related data into one table and extract only the data I need by specifying a single column/field. What I have in mind is to augment this standard api call:
... /api/docs/{docId}/tables/{tableId}/records
with an additional option like:
... /api/docs/{docId}/tables/{tableId}/fields/"[field1, field2, ...]"/records
This sort of endpoint would allow me to put all the data into one intuitively-designed table, and then grab a single column while staying under Napkin’s payload limit.
My current workaround is not bad, but since: SELECT field1, field2 FROM table is such a common approach to querying data, it doesn’t seem unreasonable to have that ability in the API. Assuming that these API calls are converted on the backend into SQL queries, adding an endpoint that sticks the field names into the query seems reasonably easy to implement (though I don’t mean to presumptuously assume anything about your workflow).
Is it possible to get an endpoint that lets us query specific fields? I would make excellent use of it right away.
All the best,
Christian