Azure / Azure/azure-functions-openapi-extension
Loading types from referenced dll's should be optional, very poor performance of generating swagger document for large projects.
- Dominant language
- C#
- Stars
- 388
- Forks
- 202
- PR merge metrics
- No merged PRs in 30d
Description
Hello,
So my case is simple - one Azure Functions project (.NET 8, isolated) with a few functions, but with a huge amount of dependencies (basically one of our third parties consists of like hundreds of dll's - don't ask me why, I don't know either but there is no alternative).
While at the end there are only a few functions to display it takes about 15-20s to generate on my machine, and much more after publishing it to low tier Azure app slot (basically it times out).
I think it's because of this [PR](https://github.com/Azure/azure-functions-openapi-extension/pull/361), this is something usable in scenarios when we want to split functions into separate projects or have some shared ones. But after all I just think that in most scenarios OpenAPI definitions will be located only in top-level assembly (i.e. actual function app), or a few of them, but total amount of references without any will be way higher than that (empty function app project builds to like 30+ dll's) so this should not be a default behavior, or at least we should be able to control it in some way.
Before moving to .NET 8 and isolated functions we were using `AzureExtensions.Swashbuckle` package, which renders UI for the "same" project (just in .NET 5) in no time, and this one is just not usable in our case.
I can think of two approaches that would not be that hard to implement:
- First is, of course, some boolean flag that would specify if we want to search only in top-level dll.
- Some abstraction over retrieving types for processing, so we can choose either to rely on a default implementation, provide our own reflection based one or even list functions manually for some reason.
Contributor guide
Research direction
Start by reviewing PR 361 and the type-loading path used when generating the OpenAPI document for isolated .NET 8 Azure Functions. Compare the referenced-DLL scan with the top-level assembly behavior described in the issue. Done means providing a documented way to control or replace type discovery and verifying that large dependency graphs no longer cause unusable generation delays.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, csharp, openapi
- Domain
- api, backend, cloud
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100