vendredi 24 juillet 2020

Best endpoint design approach [closed]

I'm trying to optimize a call that is taking ~6 seconds to load a page. It's set up like this: frontend -> backend service -> further backend services -> database.

The gist of the call is to return 3 counts, a user count, a team count, and a roles count. To the DB, teams and roles are considered the same, the only difference is the value in a column (TEAM, ROLE).

The problem lies somewhere in the backend service, because it has to make 2 other calls where one gets filtered once (i.e. linear iteration) and the other response gets filtered twice.

This is kind of how it goes:

  • The frontend calls one endpoint: /getCounts.
  • The backend has to make 2 calls to other backend services.
    • one to a user service to get the user list.
      • user list is then filtered to remove a subset of the users and we get the resulting subset count.
    • one request to the roles service that gets the list of teams and roles (combined).
      • The roles call response is filtered twice, once to filter out the teams (and get subset count) and once to filter out roles (and get subset count). O(2n).

My initial thought is to separate the team and roles call into two requests to the role service and let the database do the filtering. In theory, the DB should be able to filter faster than iterating the list through code.

The thought that followed was having an algorithm that separates the teams and roles in a single iteration of that list. O(n).

Another thing that I considered was to have 3 separate endpoints in the backend service, one for each count. And to help with render times, have the frontend do those calls asynchronously so the rest of the page can load without having to wait for the values. But this raises the question of:

Don't we want to have endpoints return resources instead of hyper-specific values?

Which of these would be the better approach:

  1. Make three calls from the backend endpoint and let the DB do the filtering.
  2. Make two calls and filter once.
  3. Have 3 separate endpoints.
  4. Something else.

Aucun commentaire:

Enregistrer un commentaire