Implementing authentication server using IdentityServer4 is pretty straightforward even if you have never done it. No big deal, install the required packages, copy-paste-change some code from the docs and you’re done. What if I want it to work in a less standard way? By less standard I mean providing scalable OAuth authentication service in microservice architecture without the use of ANY (conventional) database. Easy? Let’s have a look!
One of my countless projects I do is a WPF application. Nothing really fancy, just a plain form based app. Doing some business logic, mostly acting as a simple front-end.
I still have not fully eradicated the famous engineer pride. So I often try to do things right. Like they supposed to be done.
I don’t always succeed, one sometimes has to be a pragmatic and choose business increment over the rules of art.
But this time I mostly succeeded. I managed to solve a technical problem of keeping MVVM approach in the really unpleasant case, so I thought I will tell you how I did it. Maybe some of you will benefit from it some day.
So, currently I’m working on a brand-new project involving variety of services being run on Service Fabric cluster in Azure. I’ve never had anything to do with Service Fabric (except for one, short hackathon) before, nor have any of my team mates. For the last couple of weeks, we’ve been struggling to make good architectural choices for the platform we’re still learning about. For the last few days we were working on a service that on certain triggers will populate Redis cache with certain sets of values. The logic of such service is pretty complex, as it has to keep two data sources (Redis and SQL DB) in sync, based on some sets of business rules. Another problem is that there are millions of those values to keep in sync. I’m not going to reveal all those rules and explain all the business domain (NDA + it would take too much time). I will just give you the quick overview of how we initially approached the problem and why we were wrong.