Azure / Azure/bicep

Support HTTP Contract for Extensibility Provider (Server-Side)

Open
#6,822 1 comment 0 reactions 0 assignees View on GitHub
enhancement story: extensibility
Dominant language
Bicep
Stars
3.6k
Forks
830
Avg merge
1d 21m
Merged PRs (30d)
79

Description

**Is your feature request related to a problem? Please describe.**

The current Extensibility Feature implementation requires the Extensibility Provider (Server-Side) to be a C# class that implements the [`IExtensibilityProvider` interface](https://github.com/Azure/bicep-extensibility/blob/main/src/Extensibility.Core/IExtensibilityProvider.cs).

As a consequence:
* The Extensibility Provider (Server-Side) logic is hosted in a runtime for which I (the ext. provider author) have no access when I need to debug, log or audit.
* Any crash resulting from another extensibility provider hosted by Bicep may affect the processing of requests to my extensibility provider ([noisy neighbor antipattern](https://docs.microsoft.com/en-us/azure/architecture/antipatterns/noisy-neighbor/noisy-neighbor)).

As an extensibility provider author, I would like to have the flexibility to host the Extensibility Provider (Server-Side) in a runtime of my preference and enroll the URL that the deployment engine will call to service requests for the Extensibility Types that I defined.

**Describe the solution you'd like**

The Extensibility Provider (Client-Side) will contain the URL that services requests to the defined types, this value would be sent as part of the payload to the Deployment Engine to route requests to the Extensibility Provider (Server-Side)

The API Contract between the Deployment Engine and the Extensibility Provider (Server-Side) is defined in a language agnostic interface such as JSON-RPC, Protobuf, RestAPI

Contributor guide

Open the contributing guide

Research direction

Start with the current IExtensibilityProvider interface in src/Extensibility.Core/IExtensibilityProvider.cs and trace how the deployment engine routes requests to server-side providers. Compare the proposed JSON-RPC, Protobuf, and REST API contract options, including how the client-side URL would be sent in the deployment payload. Done means an agreed language-agnostic HTTP contract and an implementation path for routing requests to externally hosted providers.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
api, backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.