☀️ TIL 0224

⬇️ Main Note
https://docs.google.com/document/d/1glqUYKTAkGVh7C2hDpn3HgElIKo-737YMRQ7ul5_0NU/edit

---

🌵 [accessToken]

• When login verification data is requested from browser to backend server, back then, login data were saved in backend server's memory session. But for this method, once the memory is full, no more data were able to be saved.

• To solve this problem, multiple backend servers were made, which all contained same information data. Eventhough stored data were identical, solving process were different by each servers. So if AAA backend server isn't the server where particular log in history is preserved, that AAA backend server isn't able to recognize whether that particular login is done.

• And so on, to solve this problem, login information is saved into data base. But this also didn't work becuase of bottleneck effect. Since it is also not easy to duplicate multiple data bases. There came out verification table partitioning, which is partitioning the data as a table.
  ex) 1-3000 row being saved to first data base, 3001-6000th row being saved to second database...
  --> However, this method should be also accessed to data base and pull out the data. (Inefficient)

• Eventually, JWT came out. With JWT, login information is put inside the token itself. So there was no need to go through backend server and go to data base to pull out the data. But, what JWT does is checking whether the login access is on or off, so even if the information is stollen, it was hard to verify log in.

• Therefore, refreshToken is created once the expiration time is over.

---

🌵 [refreshToken]

When login is operated, 2 results were returned: accessToken & refreshToken

• accessToken is put into state and refreshToken is put into cookie.

• Let's suppose that the user is requesting for an API that needs login.
  --> Authorization will be received by requesting with accessToken. Unless the accessToken isn't expired, it will work properly.
  --> However, once the token is expired, the browser returns UNAUTHENTED error. When this error is returned, the user must check what kind of error is returned from app.tsx in browser developer tools.

• If the error is related with authorization, reissue request is sent with using refreshToken.
  --> That newly issued accessToken is put to state again --> The previous failed API was requested again with the new accessToken.

---

🌵 [GraphQL - Axios]

_app.tsx Settings

To encode data, http uri was changed to https.
To export with cookie, credentials were set include.

Also, onError() was used to make errorLink. Inside onError(), callBack function was included. As it's arguments, graphQLErrors operation, forward were put.

Inside... :

• If gql error is set, check whether the error is UNAUTHENTICATED error. Then, if it is, accessToken should be reissued bt refreshToken. At this part, apolloclient setting wasn't fully done so it was impossible to request restoreAccessToken(useMutation).
• So I requested by using graphql-request library.
• Reissued accessToken was saved into setAccessToken().
• The operation that contains recently failed query information used operation.setcontext({}) for its setting, and only accessToken was change. After all, forward(operation) was re-requested.
  --> Above errorLink was connected to ApolloClient.

PostMan gql Request

gql was always in the form of POST and it was rest-API which contained only one endPoint.
Also, underFetching problem was solved by sending data with POST.

For each request, error code was givien individually. But for total POST request, always 200 error was returned.

---