Największą zaletą Azure Functions jest skrócenie czasu, który jest potrzebny do wypuszczenia produktu na rynek. Można je również zastosować w celu przyspieszenia prototypowania aplikacji. Od jakiegoś czasu można zdefiniować mocka naszej funkcji, który w odpowiedzi na wysłane zapytanie pod konkretne API wyśle nam ustaloną odpowiedź.

Rozwiązanie to ma olbrzymi potencjał. W szczególności w przypadku różnego rodzaju prototypowania aplikacji. Wystarczy tylko zdefiniować nasz end point i wskazać jaka odpowiedź ma zostać zwrócona. Dzięki temu możemy budować od razu docelowe powiązania w naszej aplikacji. A w późniejszym etapie pracy po prostu zastąpić definicję mocka poprawnie zaimplementowaną funkcją.

Funkcjonalność ta umożliwia również zoptymalizowanie prac w zespole. Sądzę, że każdemu z nas zdarzyły się sytuacje, gdy jeden z zespołów odpowiedzialny był za front-end, drugi za back-end. Na początku prac zostały ustalone interfejsy, a po ich zakończeniu obie części aplikacji nie potrafiły się ze sobą porozumiewać. Wykorzystując to rozwiązanie możemy zdefiniować konkretne interfejsy i obydwa zespoły będą miały zmaterializowany wzór do którego będą dążyć.

Opisywana funkcjonalność nie jest jeszcze dobrze znana ponieważ nie do końca została udostępniona na Portalu Azure. Aby z niej skorzystać będziemy musieli modyfikować pliki konfiguracyjne manualnie.

Zacznijmy od początku:

  1. Funkcjonalność ta dostępna jest w ramach tzw. Proxies. Funkcjonalność ta jest domyślnie wyłączona. Musimy więc ją aktywować w ustawieniach aplikacji. Pamiętać należy jeszcze, że cały czas Proxies są jeszcze w statusie Preview:
  2. Następnie musimy zdefiniować proxy, w którym podajemy szablon adresu URL, pod którym będzie dostępne API oraz możemy zdefiniować metody HTTP, które będą obsługiwane:

    W tym momencie kończy nam się możliwość konfiguracji środowiska z wygodnego UI.
  3. Musimy przejść do manualnej edycji pliku, który posiada konfigurację aktualnie zdefiniowanych Proxies. W tym celu przechodzimy do tzw. Platform features naszej aplikacji i wyszukujemy App Service Editor. Tam wybieramy plik json i powinniśmy zobaczyć następującą zawartość: 
    {
  "$schema": "http://json.schemastore.org/proxies",
  "proxies": {
    "GetUserMock": {
      "matchCondition": {
        "route": "api/users/{userId}",
        "methods": [
          "GET"
        ]
      }
    }
  }
}

    Plik ten na razie zawiera to co udało nam się skonfigurować z portalu, ale wystarczy dodać fragment definiujący odpowiedź do definicji GetUserMock:

    "responseOverrides": {
  "response.statusCode": "200",
  "response.headers.Content-Type" : "application/json",
  "response.body": {
    "id": "{userId}",
    "name": "Michał Jankowski",
    "site": "www.jankowskimichal.pl",
    "skills": [
      "Serverless",
      "Azure",
      "Cloud",
      "Azure Function"
    ]
  }
}

    W tym momencie nasza funkcja zacznie zwracać definiowaną przez nas odpowiedź w formacie json.

    Zwróćcie proszę uwagę, że w odpowiedzi znajduje się takie same id jak w wysłanym zapytaniu.

I na koniec zamieszczam jeszcze pełną konfigurację:

{
  "$schema": "http://json.schemastore.org/proxies",
  "proxies": {
    "GetUserMock": {
      "matchCondition": {
        "route": "api/users/{userId}",
        "methods": [
          "GET"
        ]
      },
      "responseOverrides": {
        "response.statusCode": "200",
        "response.headers.Content-Type" : "application/json",
        "response.body": {
          "id": "{userId}",
          "name": "Michał Jankowski",
          "site": "www.jankowskimichal.pl",
          "skills": [
            "Serverless",
            "Azure",
            "Cloud",
            "Azure Function"
          ]
        }
      }
    }
  }
}

Check it:

Azure Functions – Lessons learned Serverless Azure – Progressive .NET 2017