acikyazilimagi / acikyazilimagi/deprem-yardim-backend-go
refactor: Data sent back to client devices could be reduced.
- Lenguaje dominante
- Go
- Estrellas
- 282
- Forks
- 51
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Descripción
### 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

- Shortened: 371148

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.
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Evaluación
Este issue todavía no se ha evaluado.