The biggest advantage of Azure Functions is reducing time-to-market of our application. We can also use them to make prototyping more effective. From some time you are able to define mock of our function in Azure Portal. Function defined as mock will respond on request according to its configuration.
I believe that this solution has a great potential. It can be very useful in all sort of application’s prototyping activities. You just need to define our end point and its response. And that is all. You can start using it in you prototype. So you define correct connections in your application from early begin. Then you will need only to change mock definition with correct implementation of your function.
There is also other benefit. You can optimize work between people in your team. I think that everybody at least once has taken part in situation when two groups – one responsible for front-end and second one for back-end – defined common interfaces. And finally both parts of this solution couldn’t talk to each other in the end. Mocks allow us to define well described interfaces by providing working end-point. With that approach both groups would have materialized version of their contract and they can use it.
Unfortunately described feature is still not so well known and popular because it has not been introduced to Azure Portal as feature that can be configured easily by user from UI. You will need to modify manually configuration files.
Lets’ start from the beginning.
- Described feature is a part of Proxies They are turned off by default so you need to enable it in application settings. Please remember that Proxies are still marked as Preview.
- In next step you need to define proxy with provided route template and selected allowed HTTP methods:
And those are all steps that can be done from user friendly Azure Portal UI.
- Now you should open and edit file that contains whole definition of Proxies. So, please open Platform features of our application. Then you should find App Service Editor and open json file. After doing that you should see the following configuration:
{ "$schema": "http://json.schemastore.org/proxies", "proxies": { "GetUserMock": { "matchCondition": { "route": "api/users/{userId}", "methods": [ "GET" ] } } } }
You can see that this file contains only configuration that we managed to set up from Azure Portal. To enable mock you will need only to add the following definition of response of GetUserMock proxy:
"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" ] } }
After that our proxy will respond with json provided in configuration.
Please note that you will find the same id in a response that was used in URL.
And finally whole configuration in one place:
{ "$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" ] } } } } }
Tak się właśnie zastanawiałem do czego te proxy służą. Dzięki za post 🙂
To jest tylko jedna z pomniejszych funkcji. Podstawowym zastosowaniem proxy jest stworzenie fasady na nasze funkcje. I tak wywołania, które zostaną otrzymane na zdefiniowane adresy proxy trafią do konkretnych funkcji na podstawie konfiguracji routingu.