Development with a Dot

Introduction This will be another post on the multitenancy subject. For now, I plan to write or already wrote: Tenant identification (this article) Data filtering (for EF Core) UI customisation Business logic If you've been following this blog, you know about data filtering with EF Core as an example. This time, I will focus on tenant identification. A tenant is identified by some id. It may have some data, configuration, etc, against it, but, for now, we just want to be able to identify who it is. Tenant Identification When it comes to identifying a tenant, there are some options: A query string parameter (mostly for testing) A route part An HTTP header A JWT token property A cookie Other options might include: Using the HTTP Host header and mapping it to a tenant Using the source IP for the request and mapping it to a tenant I won't cover these for now. A single tenant will be associated with a request, and it won't change during its pro...

Introduction Multitenancy is a hot topic, which I covered a few times on my old blog. I won't dwell on its concepts, but, instead, I will present ways to apply multitenancy to EF Core. When it comes to data, multitenancy means that we should only retrieve data for the current tenant. I will present three ways to obtain the tenant id from inside of a  DbContext , which can then be used to set up query filters, connection strings, or mapping configuration. Multitenancy in Databases So, as I blogged before, there are essentially three strategies for applying multitenancy to databases: Using a tenant column on tenant-aware tables and filter by it Using a different schema, meaning, tenant-aware tables will be duplicated in different schemas and for each request, one schema will be used Using different databases, one for each tenant, and, for each request, pick the right connection string There are obviously pros and cons to each approach, but I won't go through them now. Instead,...

This was ported from my original blog post here . Introduction When you have an existing deployed REST API that you want to change, you generally need to be very careful. Why would you want to change it? There can be a number of reasons: Changes to the request contract (adding, removing or modifying request parameters) Changes to the response contract (same as above) Changes to the behaviour of the existing actions (they now do something slightly different) Changes to the HTTP methods that the existing actions accept (not so common) Changes to the HTTP return status codes … In a controlled environment, you can change at the same time the server and the client implementations, which means that you can update your clients accordingly, but, unfortunately, this is not always the case. Enter versioning! With versioned APIs, you can have multiple versions of your API, one that the legacy clients will still recognise and be able to talk to, and possibly one or more that are more suitable for ...

This was ported from my original blog post here . Introduction The concept of getting the location for a given IP address is not exactly new, and some posts have been written about it already. Still, I wanted to write about it because I will need it for a later article, and, to add something, also explain how to get the weather forecast for the given location. Let's start by getting the location for a given IP address. Geo Location There are plenty of services available for free or a fee on the Internet that will give you some information about the location of an IP address (geo location by IP). To name just a few, in no particular order: https://www.iplocation.net https://hackertarget.com/geoip-ip-location-lookup https://ip-api.com https://ipapi.co https://freeipapi.com https://ipgeolocation.io Some of these offer free services (with possibly some limitations, such as rate limiting per hour/day) where others offer full working sets. Also, the amount of information varies, al...