Handling promises resolvers with an in-memory `Map` object
Hello folks,
I am developing an app that's using a structure similar to the one in the attached
index.ts file.
The project I'm building requires starting a request from one client and "confirming" the request from another client. This means that client A must reach out to the /hello-request endpoint, and client B must use /hello-confirm/:helloId to resolve the request. This also works under the assumption that client B would be sent the helloId value in a separate step.
Understandably, this kind of callback-driven request structure isn't ideal. However, it is the design I must use in the constraints of my current project.
Broadly, I have 3 questions:
1. Is there a better way to handle having an in-memory storage of pending requests and their resolvers? I am assuming that a top-level Map object that can be passed between routes and submodules should work, but I'm unclear if there are any mutability or concurrency issues I might run into.
2. Are there performance issues with this approach? Other than scalability (i.e. I don't think this can scale horizontally), is there a more performant way to handle setting and getting pendingRequests from the top-level in-memory storage?
3. Better yet, is there a different way you'd approach this same project requirement (handling an initial request and resolving the request from a different endpoint)?
Thanks for your help!1 Reply
GitHub
Handling promises resolvers with an in-memory
Map object · honojs...Hello folks, I am developing an app that's using a structure similar to the one below: import { Hono } from "hono"; import { HTTPException } from "hono/http-exception"; impo...