-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IMN 606 - BFF purpose scaffolding #645
Conversation
b28e8da
to
63b9beb
Compare
63b9beb
to
af95ab8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some minor comments, looks good!
headers: { ...requestHeaders }, | ||
withCredentials: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will these two lines need to be duplicated in each client call? We could think about a way to avoid this and also the duplication of the definition of requestHeaders
in each router call, even in a further PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a good solution right now, the only idea that I have is to wrap the client request in some way to inject these parameters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMN-606
How we currently handle the "zodiosPatch" for the BFF package is not optimal. Before implementing other solutions that require refactoring on other packages I'd like to discuss the
openApi spec first
strategy.