Scale the UI / Backend: Pagination - Githubissues

rivernews / appl-tracky-spa

An Application Tracking System to help job finders ease their out-of-control spreadsheet use tracking every job application record.

https://appl-tracky.shaungc.com

1 stars 0 forks source link

Scale the UI / Backend: Pagination #86

Closed rivernews closed 3 years ago

rivernews commented 3 years ago

As more and more company created, the frontend is currently loading everything (almost the entire database, all companies + all applications, ... etc) even if each request is paginated. We may want to consider better scaling the following:

Fetching company to list them in UI
- mechanism to load more: infinite scroll VS next page & redux only store current page data?
Searching company

There's also new opportunity to adapt new technology, such as GraphQL here.

e.g. The home page list should not load entire application data, just the application position name is sufficient
See django migrate from rest to graphql (YouTube video)

rivernews commented 3 years ago

In frontend, looking at the homepage.

[x] Stop traversing next or endCursor in saga-factory.
[x] Action accept a new arg - for Graphql endpoint, the after.
[x] Object redux suite store add a field endCursor.
[x] In saga-factory, after fetching graphql, store the endCursor into the object's redux store.
[x] Move the fetching logic from auth-saga to homepage.
[x] In saga-factory, we may just use the existing endCursor in the object's store as the arg after when fetching graphql.

Some remaining issues.

[x] Search function relies on the currently loaded data. Let the search function be de-coupled from the company / grouped company redux store, only fetch and display from graphql endpoint data.
- [x] Current logic only filter from redux data. Need to change to request backend API upon search.
  - [x] Need to prepare API for search. Could use django-filter's __contain.
  - [x] Need to prepare React client to support search
  - [x] **May need a new redux bucket for search result companies if want to use existing factory trigger actions. Otherwise will have to do the entire API request manually in the page component
    - Advantages to go for reuse trigger action route - can reuse "load more" button logic and pagination out of the box, can reuse the related object normalizer easier, etc.
    - If we want to also "store/cache" the search result - we need to maintain grouped company redux. The thing is, we don't have a company->eachGroupCompany kind of redux suite. We manually triggered each groupCompany suite.
    - However, we not necessarily need to store the search result, it could be temp and the search feature will be fine.
- [x] Later on if we want to store the search result, we probably need to deal with how to put (dispatch SUCCESS state) companies of different status into each grouped company.