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.

Open
#630 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.