-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: Use $api
client for requests from Hasura → API
#2297
Conversation
166fa8e
to
336ef97
Compare
336ef97
to
2717e01
Compare
Removed vultr server and associated DNS entries |
$api
client for request from Hasura → API$api
client for requests from Hasura → API
*/ | ||
export const $admin = new CoreDomainClient({ | ||
auth: { adminSecret: process.env.HASURA_GRAPHQL_ADMIN_SECRET! }, | ||
export const $api = new CoreDomainClient({ |
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'm not totally thrilled with the name of this at it feels a little unspecific, but it follows the existing pattern of $<ROLE>
being the client for that role.
We could rename getClient()
-> getUserClient()
which returns a $user
, but similarly this feels a little unclear as you could end up with $user.user.addUser(newUser)
🫠
What does this PR do?
$admin
client with the$api
client (see comment on naming conventions) which is scoped to the "api" roleuseHasuraAuth()
auth middleware - these functions are all triggered by HasuraWhat about tests?
Yep, this is tricky. Introspection tests cover the permissions the
$api
client has here. Some of the functionality is covered by E2E tests (send, invite to pay) - some is not (submit, export).I think the best solution here in the medium term is to probably work to improve our E2E test coverage for high-priority functionality.