Glass needs to handle a lot of data. Almost all of which comes from Proximity in the JSON:API format. A feature of this format is that every request has exactly the same structure, with only the data differing. Following the JSON:API format has many benefits, but one of its drawbacks is the fact that JSON:API messages contain a lot of boilerplate (informationless structure). Because glass has to handle a lot of data, this boilerplate can increasingly slow down our requests the more data is transmitted (compared to raw information). What I would like to propose is the supporting of compressed messages by proximity, an optional feature that strips these responses from their boilerplate, allowing us to sidestep some transmission overhead.
I think that this could be achieved within a cycle of 4 weeks. In proximity we would have to setup a system to compress the data and in glass we would have to setup one to decompress it. The compression and decompression can be made simple at first, and more complex compression techniques can be implemented when needed. After finishing the feature I doubt that much maintenance will be needed since the transformations will only be dependent on the JSON:API structure. This is also the reason why I think that this will easily scale to new resources. It only needs to be implemented once.
{MORE RESEARCH NEEDED} I think we can decrease the size of each record with 50% or more so the transmission overhead will go down quite a lot. It will, however, require more processing because the data needs to be compressed and decompressed again. It's essentially a tradeoff between network and processing power. The thresholds for this becoming worthwhile are still unknown. I'm not actually sure how much the content size affects total request duration. I setup this issue on stack overflow to find out.
Good idea! Would be interesting to test what standard HTTP gzip compression already achieves on regular uncompressed payloads.