Microservices with .Net Core API and Azure Service Bus

Basic Microservice Architecture with Azure Service Bus and API Gateway

The above Architecture has the following components:

Front-end: ReactJS Application with a simple form hosted on App Service Plan which will hit the API Gateway with GET/POST requests.

Name Microservice: First Microservice hosted on App Service Plan that will take User Details from front-end and save PersonId and Name in it’s own Azure SQL database.

Azure Service Bus: The Name Microservice will forward the PersonId created and Address details from front-end to the Azure Service Bus Topic.

Address Microservice: Second Microservice hosted on App Service Plan will subscribe to the Topic that takes PersonId and Address data from the Name service and store the details in it’s own Azure SQL database.

This is not an ideal scenario for creating Microservice Architecture but it shows the idea how the individual components interact with each other.

*In addition to this, another Azure Function will subscribe to the Queue for new User creation and sends email to someone with the details. This is however, not shown in the above image.

The Front-end Application is a form created in ReactJS that takes in following fields from the User:

FirstName, MiddleName, LastName, Email, Phone Number and Address

The following front-end and back-end repositories have all the code for connecting to the required components.

Further, a separate Authentication Microservice can be created which will return a JWT token based on the credentials provided. The token can then be validated by the API Gateway configured with the API Manager Service and then allow the requests to go through to the other Microservices.

The front-end code does not have Login page in this sample, however it directly passes the credentials to the Auth Service to generate the token. The token is then passed through to the subsequent calls to the API Management Gateway.

Select Validate JWT policy for Inbound Processing at the Operation Level for APIs under API Management.

Change the issuer signing key while adding the Inbound Policy under API Management as per the key used while generating the token from your Authentication Microservice.

<inbound>
        <base />
        <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized">
            <issuer-signing-keys>
                <key>xxxxxxxxxxx</key>
            </issuer-signing-keys>
        </validate-jwt>
    </inbound>

Also, make sure the CORS policy is updated under the respective APIs Inbound Processing at the required operations or All Operations level:

<cors allow-credentials="false">
            <allowed-origins>
                <origin>https://mywebsite.azurewebsites.net</origin>
                <origin>http://localhost:3000</origin>
                <origin>https://mypoc.servicebus.windows.net</origin>
            </allowed-origins>
            <allowed-methods>
                <method>GET</method>
                <method>POST</method>
                <method>OPTIONS</method>
            </allowed-methods>
            <allowed-headers>
                <header>Authorization</header>
                <header>Content-Type</header>
            </allowed-headers>
        </cors>

Update the connection strings as per your Database and Service Bus Services from the Code Repository provided above.

Another example of Microservices Architecture for a real world scenario is as below:

Microservices Architecture for Online Shopping Application

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.