Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
budancamanak opened this issue Feb 11, 2023 · 0 comments
Open

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

budancamanak opened this issue Feb 11, 2023 · 0 comments
Labels
discussion bu konuyu tartışmalıyız improvement mevcutta çalışan bir şeyi iyileştirmek isteği waiting-approval pm onayı bekleyen issue wontfix üzerinde çalışılmayacak iş, iptal, istenmeyen geliştirme

Comments

@budancamanak
Copy link

budancamanak commented Feb 11, 2023

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):

  • Original: 489716
    image

  • Shortened: 371148
    image

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.

@budancamanak budancamanak added discussion bu konuyu tartışmalıyız unchecked henüz check edilmemiş pr veya issue labels Feb 11, 2023
@giveerr giveerr removed the unchecked henüz check edilmemiş pr veya issue label Feb 11, 2023
@yusufgns yusufgns added the waiting-approval pm onayı bekleyen issue label Feb 11, 2023
@mstrYoda mstrYoda added wontfix üzerinde çalışılmayacak iş, iptal, istenmeyen geliştirme improvement mevcutta çalışan bir şeyi iyileştirmek isteği labels Feb 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion bu konuyu tartışmalıyız improvement mevcutta çalışan bir şeyi iyileştirmek isteği waiting-approval pm onayı bekleyen issue wontfix üzerinde çalışılmayacak iş, iptal, istenmeyen geliştirme
Projects
None yet
Development

No branches or pull requests

4 participants