Open resir014 opened 3 years ago
@k1m0ch1 has also started working on proper pagination for his API:
Would love if https://jkt-vax-quota.vercel.app/ is not accessed directly by client, because it is VERY volatile. It will bork out WHEN (not if) JSC team change their column metadata (column type, such as number/string/datetime, or column omissions which happened a few times) cc @resir014 @k1m0ch1
just realized pagination is hard to do with (fuzzy) search, unless the API also handle both filter & pagination
maybe we can try virtual list first and see if it fixes performance issue?
just realized pagination is hard to do with (fuzzy) search, unless the API also handle both filter & pagination
maybe we can try virtual list first and see if it fixes performance issue?
yes I would like to update this, currently I'm using the full buffer to read file, need to switch to stream file to read file
Yes, let's do that. @pveyes
ok just made a WIP at #73
few issues:
@pveyes so are we going with pagination (#76) or virtualised list (#73)? Seems like we'll have to pick one from the other to go forward.
Although if we were to move to pagination, we'll also have to move search to the backend as well. But I guess we can live with client-side fuzzy search for now?
EDIT: I guess we'll go with client-side pagination for now. We can start from there if we were to move to virtualised list
Description
With the recent update to the vax API, the site's now loading slowly due to the number of data. We should implement some form of pagination to help reduce the number of content rendered.
Implementation Model
A basic pagination query of the API is now available on the API. https://jkt-vax-quota.vercel.app/
Available queries: start (default 1) and count (default 100).
e.g.
https://jkt-vax-quota.vercel.app/api/kuota?start=10&count=100
Tasks
[TODO]