[INSPIRATION ONLY] - pseudo-implement asynchronous request-reply design [DO NOT MERGE]

[thomasyu888]

Problem
There are endpoints that take > 1 second to return a response, it is best practice for API endpoints for these to return fast

Solution
Use celery + redis and the async request reply design pattern. https://learn.microsoft.com/en-us/azure/architecture/patterns/async-request-reply. NOTE: this PR does not fully work, but it meant to showcase some tech that can be used.

What didn't work about this PR was the connection between redis and celery in the docker containers locally.

Here's a rough sequence diagram that may not be fully correct (ie the status codes, etc)

[linglp]

@thomasyu888 very interesting. I looked into turning schematic APIs to async a long time ago when we were still doing tiger team, and also saw celery + redis pattern. I could do more research into this too.

[afwillia]

@thomasyu888 how did you make this diagram?

[thomasyu888]

Thanks both for looking at this!

@linglp before you dive deeper into this, lets focus on the tasks at hand and we can align as a group what gets tackled next

@afwillia See this. That said, you can write a GPT prompt like this:

I am a software architect and I would like to generate the markdown code for mermaid sequence diagram for the below code (paste the code)

[BryanFauble]

⚠️ To be aware of if looking to implement this ⚠️

If we implement an async job queue in front of schematic. Now schematic would intentionally have request-to-request persistence. We would likely want to match the sub in the JWT claim to the status of the job they're requesting to make sure they match. This is to ensure we are properly having an authorization check in place to prevent user "A" from requesting information about the job of user "B".