Skip to main content

AZ-204 Azure Redis Cache

Why should we cache?

1. Because we dont want to hit the database everytime.
2. Caches store data in memory, so its faster to query them.
3. Caches use a key value pair to store data rather than any complex data structure, So the time complexity is less.
4. Also it improves availability, as if the backend in unavailable we can still get the data from the cache. Not all of it but the most frequently used ones. So its important to make sure that we are caching the right data.



















Azure Cache

1. Geo Replication: The main copy remains writable whereas the other copies are maintained as readable. So not only is the data available in a new region but also available in case the primary cache is down. In such a scenario the secondary instance becomes writable.


DATA Types
























NUGET

Microsoft.Extensions.Caching.StackExchangeRedis -- allows more data types and operations

 services.AddStackExchangeRedisCache(op => {
                op.Configuration = "Connection string from azure redis";
            });


  var data = await distributedCache.GetStringAsync("sales");

                if (!string.IsNullOrEmpty(data)) return  Ok(JsonConvert.DeserializeObject<IEnumerable<Sales>>(data));


                DistributedCacheEntryOptions cacheEntryOptions = new DistributedCacheEntryOptions();
                
                //invalidate or expire the cache after 0 days, 1 minutes and 30 seconds
                //absolute expiring will expire the cache after the specified time
                cacheEntryOptions.SetAbsoluteExpiration(new System.TimeSpan(0, 1, 30));

                //sliding expiration will expire the cache if its not used for the specified time
                cacheEntryOptions.SetSlidingExpiration(new System.TimeSpan(0, 20, 0));

                var result = SalesdbContext.Sales.Take(20).ToList();
                await distributedCache.SetStringAsync("sales", JsonConvert.SerializeObject(result));
                return Ok();


While connecting we might get an issue,











































Comments

Post a Comment

Popular posts from this blog

Azure AD Authentication And Authorization

ROLE BASED AUTHORIZATION Step1:   Setup  API. 1. Create an app registration and create an app role. Make sure that the app role is assigned to user and applications. We add it to both user groups and applications as this role can be then assigned to both users and applications. Scopes can only be assigned to apps. Now we can have only users with this role access our application. This app role behind the scenes adds an approles section to the manifest.json. We can directly add it to the manifest file also. Step 2:  Setup an app registration for the UI/ WEB App. . We will grant this app the read role created in the API app (shown above). Go to Azure AD and select the UI app registration. When we register an application 2 elements get created. 1. App registration  2. Enterprise Application -- service principal that get created for the app Adding roles to applications Go to the App registration => API Persmissions => Add a Permission => My API's The My Api's sec...
Post a Comment
Read more

Function APP and KV integration

 Create a function App and enable system assigned identity Create  a Keyvault and add a secret (Name in my case) Configure Access policies for the function app in keyvault Create an  access policy in Key Vault   for the application identity you created earlier. Enable the "Get" secret permission on this policy. Do not configure the "authorized application" or   applicationId   settings, as this is not compatible with a managed identity. https://docs.microsoft.com/en-us/azure/app-service/app-service-key-vault-references Key Vault references currently only support system-assigned managed identities. User-assigned identities cannot be used. We are granting our function app permissions to get and list all the secrets in this keyvault. Add Key Vault secrets reference in the Function App configuration Go to the keyvault and click on the secret we just created. Copy the secret identifier. We need to add this value to the function app configuration.  @Microsof...
Post a Comment
Read more

Service Endpoints --

 1. Create a VNET with 2 subnets 2. Create a service endpoint policy. That enables us to specify which particular storage account to connect to. This is currently enabled for storage accounts alone. Otherwise as part of service endpoints we can specify the resource provider alone and not a specific resource. We can specify this service endpoint policy while creating a service endpoint. Only storage account allow service endpoint policies as of now. If we notice then selecting cosmos db or any other service other than storage will not have the ability to accept service endpoint policies. As mentioned microsoft.storage allows us to add service endpoint policies. Thus we can specify a particular resource within a provider This is 1 way of enabling service endpoints. Or we can directly go to the storage account and from the networking tab select Sub1. This will automatically configure service endpoints and will add a service endpoint policy that enables the resource to connect to the s...
Post a Comment
Read more