-
Notifications
You must be signed in to change notification settings - Fork 7
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
Introduce WebApplication abstract resource to create "dev-only" ASP.NET Core-webapps #12
base: main
Are you sure you want to change the base?
Conversation
XML comments are still missing, but the Yarp sample works as expected. |
This feels a bit premature. What do you see this being used for outside of being an implementation detail |
General plan is get to hosting a AWS Lambda function within a "volatile" webapp that fakes the AWS Lambda API contract. In this way we can pass the endpoint of the lambda to the caller that can use it to customize the ServiceEndpoint property of the client performing API calls to Lambda. I understand I can just copy/paste the "hosting" part of the YARP package, but I thought it was worth trying creating an abstraction. |
I think I need to see that working before I merge this. Usage outside of the YARP resource. |
Do you prefer I append that experiment into this PR or create a new one with this as base? |
ciao! I worked on a PoC for the AWS Lambda integration and added in this repo https://github.com/Kralizek/LambdaAspire . The repo is private for now but I invited both you and @normj as collaborators. The code that actually invoke the lambda function is extremely dirty and not generic enough. Also the Aspire Hosting API can be improved. Finally, to debug the the developer will have to attach the debugger on the AppHost project. I don't know what happens in VS, but the Rider plugin doesn't do it automatically. Added note: I realized that the YARP / WebApplication resource has the start of the inner web application bound to the presence of any environment variable. Added a commit to this PR for fixing the WebApplication resource. If you want I can cherry pick this fix into the YARP one too. |
Very much a silly experiment.
I took most of the YARP resource and packaged into an abstract class that can (theoretically) be reused for creating other web apps that exist only at dev-time.
Do you guys like this or do you think it's a waste of time? Ideally, I'd love to extract the "ConfigureBuilderAsync" and "ConfigureApplicationAsync" from the LifecycleHook class because it's not very discoverable.
On the other side, I like how "clear" the Yarp package is now: its intent is very clear. Now I just have to make it work again :P