Avoid GET after POST in Frontend

[matthew-white]

I'm trying to think through whether it's possible/desirable to reduce how often Frontend needs to send a GET request immediately after a POST.

For example, when a user visits the app users page, Frontend requests the list of app users for the project (with extended metadata). If the user then creates a new app user, the response for that POST returns data for the new app user (without extended metadata). Yet Frontend doesn't use the POST response and simply refreshes the list of app users. It does so for two reasons:

• By refreshing the list of app users, Frontend doesn't need to know where in the list the new app user should be inserted. That means that outside of testing, Frontend does not need to know anything about how lists are sorted: that logic is centralized in Backend.
• Frontend uses extended metadata to render the app users table, but the POST response does not include extended metadata.
  • One idea: could the POST request indicate to Backend that it would like the response to include extended metadata? Or does logic around extended metadata really only belong in the GET endpoints?
  • Another idea: Frontend could modify the response, adding the extended metadata itself. Extended metadata for app users includes two things: lastUsed and more details about createdBy. But for a newly created app user, Frontend already knows both of those things: lastUsed is null, and createdBy is the user currently logged in. However, one downside of this approach is that if/when we add other extended metadata fields for app users, we may need to add those fields to Frontend as well.

It'd be great for Frontend not to send an extra request if it doesn't need to, but I'm also wary of premature optimization and of adding complexity to Frontend. @clint-tseng, do you have thoughts about whether it makes sense to try to eliminate this sort of request, and if so, what a good approach might be to do so?

[issa-tseng]

accepting X-Extended-Metadata on POST/PATCH might be reasonable but would similarly be an extra database round-trip on the backend anyway.

but all of this seems really complicated for a small optimization.

[matthew-white]

OK, that sounds right. I'll go ahead and close this issue!