Skip to content
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: proposal for server agnostic handlers sample #2150

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

sloops77
Copy link

@sloops77 sloops77 commented Jan 21, 2025

@TimoGlastra
I wanted to see it in code and get your initial thoughts on the following to complete #2147. there is a little bit of cleanup still to do but i think you get the gist.

The main issues that I want to draw your attention to are:

  1. The new handler not being dependent on express, only node:http
  2. The XXXModuleConfig not being dependent on express, only the XXXModule
  3. The use of the dependencyManager to get access to the XXXModule router when required
  4. Conversion to always throw exceptions from the handler and rely on catch within the router to send the error response

@sloops77 sloops77 requested a review from a team as a code owner January 21, 2025 04:09
Copy link

changeset-bot bot commented Jan 21, 2025

⚠️ No Changeset found

Latest commit: 395cc45

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Add missing await
expressApp.use('/oid4vci', issuer.agent.modules.openId4VcIssuer.config.router)
expressApp.use(
'/oid4vci',
(issuer.agent.dependencyManager.registeredModules['openId4VcIssuer'] as OpenId4VcIssuerModule).contextRouter
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be easier, as users of the frameworks have to do this registration step as well. It should not rely on dependency injection or type casting. this is also why the router was available on the module config (where I think it should stay)

Comment on lines 8 to 13
export interface OpenId4VcRequest<RC extends Record<string, unknown> = Record<string, never>> extends Request {
requestContext?: RC & OpenId4VcRequestContext
requestContext?: OpenId4VcRequestContext<RC>
}

export interface OpenId4VcRequestContext {
export type OpenId4VcRequestContext<RC extends Record<string, unknown> = Record<string, never>> = RC & {
agentContext: AgentContext
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this change needed?

Copy link
Contributor

@TimoGlastra TimoGlastra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the PR, it helps to understand the approach. My thinking was a bit different, and have better separation of express from the main implementaiton. As now it's sort of implemented around express, but you can 'hack' your way around it.

A problem with this model is that you now have to depend on internal apis (registerXXEndpoint methods).

I also don't like that we have to move the router to the module (but i think this can be solved by not making the config or module dependant on express at all anymore).

I think we just need an interface to register an endpoint? You can provide that to Credo. What we have to support:

  • variables in the path
  • method
  • maybe more??

we will have to rewrite some middleware (around issuerId and issuer injection), but if we go generic, I think it's important to do it properly.

Again, thanks a lot for this PR, it's really appreciated :)

Comment on lines +1 to +16
/*
* Copyright 2025 Velocity Team
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is not important at this stage of the PR, but just as an FYI:
I would rather not add these headers to all files. IF you want copyright credited, it can be added to the main license file (see example from Ontario: https://github.com/openwallet-foundation/credo-ts/blob/main/LICENSE#L190)

@TimoGlastra
Copy link
Contributor

And as I said in the issue, I think it might make sense to rely on native web Request/Response format. An issue with the current implementation I see is that your custom http implementation now needs to know about errors like Oauth2ServerErrorResponseError and map that to a http response.

If we want the endpoint implementations to be part of the public api, it should take care of this. Otherwise everytime we add a new error type, it will become a breaking change.

For example the Next.js api for adding routes depends on the Request and Response types. Based on that you can map it to different server implementations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants