Ivan Sedlak

This was the first project I did on Toptal. My job was to make a back-end library that would standardize the security model. I designed and implemented the code that supports multiple identity providers using OWIN middleware.

Some of the supported providers were Azure AD, custom SAML IdPs, ASP.NET Identity login, and Facebook. I also designed and implemented a custom change-aware lazy-load caching solution, application, and low-level database auditing solutions, various helpers, and base classes.

The library set a standard for other developers to follow and make their job easier as they could just use the exposed methods and properties, which made their code a lot easier to develop and maintain with one-line solutions to get current user properties, set claims, authenticate, access cached data, register a new user, authorize the user to access a resource, etc.

I had a great time working on this project as I enjoy designing the back-end libraries and standards to make developers' lives a bit easier and solutions more maintainable and secure.

My initial job was to get familiar with the solution and specific database conventions.

After that I started working with CSLA.NET to create business objects that are used for ORM and making Web APIs to expose that data to specific set of security roles.

I also helped developers working on front-end to utilize exposed data using AJAX calls.

Most complex thing I worked on was the advanced scheduler that takes a lot of different things into consideration to determine available places and times and based on selected algorithm makes the scheduling, creates games and assigns teams. This was done in pure T-SQL to keep it as close to database as possible to avoid doing a lot of plumbing to get and write the data in CSLA.NET framework (avoided creating a lot of business objects). Scheduling works fast and has validations and data corruption prevention built in, even a read only mode (transactions are not persisted).

I had a great time working with the client. The work was well organized, using JIRA and daily Scrum and story grooming meetings. This was the biggest solution I've worked on and also the most complex T-SQL code I've written so far.

I implemented synchronous (sync) and asynchronous (async) actions using web callbacks and HTTP(s) Web API using Azure Functions and Azure Durable Functions. The API is composed out of Function Apps which contain one or more HTTP request handlers.

Authorization and routing were handled with APIM (reverse proxy on steroids). The data was kept in both SQL and NoSQL data stores depending on the use case. Rapid scaling capabilities, good solution design, and overall system stability handled all the spikes in live traffic without increasing the failure rate.