acikyazilimagi / acikyazilimagi/deprem-yardim-backend-go

refactor: Data sent back to client devices could be reduced.

未关闭
#85 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
discussion improvement waiting-approval wontfix
主要语言
Go
星标
282
派生
51
PR 合并指标
30 天内没有已合并 PR

描述

### Refactor Request

**discord username: @budancamanak#9385**

**Is your request related to a bug or problem? Please explain.**

This is not a bug but a data retrieval enhancement proposal. From what I've seen, backend will return results as ```json``` which is known for its easy usage, interoperability and being **human-readable**. All fields will be put to ```string``` which will be carried over the network to client devices eg: a user in need with bad network conditions. We must send minimum data back to clients whenever possible.

**Describe the problem in a clear and concise way. For example, "I'm having problems reading the code because [...]".**
Network requests to retrieve marker data from server could have thousands of rows. Each row consist of fields listed below:

- id (2 chars)
- loc (3 chars)
- entry_id (8 chars)
- channel (7 chars)
- epoch (5 chars)
- twitter (7 chars) => this is not a field but a long channel name.

Following url has been used for calculations:
```https://apigo.afetharita.com/feeds/areas?ne_lat=37.896558262942115&ne_lng=37.92954089003256&sw_lat=37.03406827871118&sw_lng=36.38788890802672&time_stamp=1676030188```

API returned a result of ```4725``` rows.
A map detailed below could be used to shorten fields:

- id: i
- loc: l
- entry_id: e
- channel: c
- epoch: t
- twitter: 1

Json response length before and after operation is [_(response retrieved from url mentioned above in a gist):_](https://gist.github.com/budancamanak/8371b83a6b965561d0acd2fffefdf3db)

- Original: 489716
![image](https://user-images.githubusercontent.com/1699890/218226043-69c159c6-e5cf-4605-b99e-9d1bab4f03ab.png)

- Shortened: 371148
![image](https://user-images.githubusercontent.com/1699890/218226018-3324cdc2-1b50-494e-a8a3-b11d4c27e629.png)

This could give us %24 decrease on the output json string hence _I think_ increase on performance.

### Fix Recommendation

If you have a fix in mind, please explain.

I thought we might need to shorten field names to be used to construct json data on the server which could reduce payload. Shortening fields might seems odd but all fields described above could be handled by one unique character. We must define unique chars to map fields returned, document it and notify front-end team to update their structure to use mapped chars. Or a mapper function can be developed to be used to unmap chars to fields on successfull data retrieval on client devices.(Just a quick suggestion, frontend team must decide).

### Additional Context

I know results are being compressed before sending to clients. But I believe by modifying content of response, we could compress a bit more.

Edit: This scenario would require Front End team to adapt which requires a bit development.

I'd like to hear your comments.

贡献指南

这个仓库没有索引到贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。