We are doing a POC with SuperTokens for authentication. We require Passwordless, Email/Password, and Social Login functionality. With that functionality required, is the SuperTokens Core Api layer scalable? If so, what is the recommended approach for scaling?
SuperTokens has two sets of APIs:
Core driver interface (CDI): The API exposed via the SuperTokens Core microservice.
Frontend driver interface (FDI): The API exposed via our backend SDK.
Your app's frontend only calls the FDI APIs and in turn, our backend SDK calls the CDI APIs. So your backend is a proxy between the frontend and the SuperTokens core service.
The scalability of the FDI APIs (which is called by your frontend) is dependent on the scalability of your API layer - which is completely controlled by you.
The scalability of the CDI APIs (exposed via the SuperTokens core service) depends on:
The number of instances of the core that have been deployed.
How "far" away is the core from your backend.
The scalability of the underlying database that the core connects to.
Each SuperTokens core instance is stateless and can be scaled up / down easily. However, all of them need to connect to the same instance of a db and therefore the limiting factor here becomes the scalability of the db itself.
Since only your backend API layer queries the SuperTokens core, it is recommended to host the core in the same region as your backend.
That being said, one instance of the core can handle several hundred requests per second comfortably. You can further improve it's performance by setting:
The max number of parallel requests to server
The max number of parallel db connections.
Finally, if we consider the different types of auth operations, session verification is by far the most common operation (as compared to signing in / out or changing a password...). By default, SuperTokens verifies a user's session in a stateless manner. This means that your backend API layer doesn't need to query the core at all for session verification.
This in turn implies that you can easily scale SuperTokens to handle millions of users with hundreds of thousands of concurrent sessions with a fairly low number of core instances.
Related
We have an application which has set of APIs developed in .NET CORE and UI which consume these APIs developed in Angular(both are independent projects) . Both are hosted on azure app service.
WebAPI integrates with 3rd Party APIs. Some of those transactional
APIs are very time consuming, so we want to have fire and forget way
of calling those and have them notified when they end.
Once our API receives the response from 3rd party, we want that be notified to UI
So we want some messaging or Pub-Sub mechanism to achieve this
I am in consideration of SignalR and Kafka.
From the documents that I red about SignalR it seems that it can be used between API -client, so I can use this for 2nd scenario.
Can SignalR be used between 2 APIs?
Coming to Kakfa , it seems to be good one for high end data streaming which I consider as over-engineering for our requirement.
Our application will be on both Azure and on-prem so we also went through Azure service bus but there is limit on Message length and cost seem to be problem for us.
So I want to know if there are any ways I can have this communication eased between 2 WebAPIs application?
Server-side Blazor maintains connection to the server-side apparently, using SignalR.
SignalR is the service you need to pay for. As many simultaneous connections to SignalR are going to be used as many online users your app has at the moment of time.
Do I understand correctly, that I will need to pay for next SignalR tier once I reach certain SignalR free tier limit? And only because I use Blazor, not that I use SignalR for other purposes.
And two cost-reduction alternatives are:
use client-side Blazor WebAssembly
don't use Blazor at all
We run 3 instances of P3V3 app service to serve ~450 users (it is a LOB app, so open by most users, most of the day)
Our SignalR service cost is double the app service plan.
You can use signalr over websockets instead of the SignalR service, but for some unknown reason it is unstable and you'll see lots of signalr connection drop outs.
There's no way to save costs on SignalR - no reservations, no bulk discounts.
I'm learning how to design and implement microservices using serverless technologies. I'm trying to create autonomous microservices and am having difficulty understanding how to communicate data across/between microservices. I'm using .Net Core for my microservices and am wanting each microservice to be a AWS lambda function exposed via API Gateway.
I have the following scenario:
Institution microservice - returns a list of institutions within a radius (25 miles) of a zipcode.
ROI Calculator microservice - receives a zip code as input and calls institution microservice receiving a list of institutions. For each institution returned, perform a series of calculations yielding a ROI value.
How should ROI Calculator microservice make a call to institution microservice?
ASP.NET core web api application can be published as it is on AWS Lambda as Serverless function. You get everything that regular .NET core application provides like controllers , models etc. Amazon API gateway proxy is integrated directly into .NET Core api routing system. So your AWS lambda function will be serving your .Net core web api. You should watch this tutorial for starters to get better understanding.
Create .NET Core AWS lambda function
.NET core AWS Lambda Microservices
If you go by template provided by AWS SDK (ASP.NET core web api template) and you publish .Net core web api on AWS it will configure everything for you including AWS Lambda function and API gateway. So if you have create 2 .net core web api projects you will have 2 web api gateways. The problem is if we have 10 microservices mean we will have 10 api gateways , so we should ideally have 1 api gateway for multiple microservices.
I have worked on POC recently that has one API gateway and all microservices AWS lambda functions are behind this. Each microservice has base path e.g. shopping or users setup in their startup.cs that will identify them individually behind apigateway. so microservice 1 will be apigateway/shopping/{anything} , another microservice will be apigateway/users/{anything} and they both are configured behind api gateway. API Gateway will send request to AWS lambda function (.Net core web api) and this request will be resolved by .Net core routing system. Even multiple controller can be used this way in a single web api project without problem.
I have modified serverless.template so we can only publish aws lambda function and configure apigateway seperatley. You can find code sample and details on my github blog here .NET Core Web API AWS Lambda Microservices Sample .
There are two ways of doing this depending on your independance of the microservices is probably the best answer:
Make a internal HTTP call from the ROI -> Institution which would be okay. The problem with this is that if the service is down the data will not be available.
Store the data needed to make the calculation inside the ROI service as well. This seems strange but the data once created in say the Institution service it could be sent via a message bus to the ROI service which then uses the data when needed. (this however may not suit your domain, it depends what information it needs).
However it seems that the calculation and the storage of the Institutions could be within the same microservice therefore eleminating the problem.
I am developing a mobile application using Telerik Platform. The services consumed by the app are ASP.NET Web API RESTful services which are hosted on Azure. I'd like to build some resilience into the app by adding a service bus and have been looking at Azure Service Bus which seems to be what I'm looking for.
It's fairly new to me and I have a few questions.
Can Azure Service Bus be used for RESTful services that return data or are they fire-and-forget only?
For simple RESTful services is Azure Service Bus the way to go or Azure Storage Queue? When would you use one vs the other?
When would I use a Queue vs Topic / Subscription?
ASB is about messaging. You use messaging for communication between parts of your system/services. RESTful services can leverage ASB by translating a request into a message to perform some work. Emphasis on converting the intent into a message, to instruct about work that needs to take place, not execute the work itself.
ASB or ASQ is your choice. This is where you need to choose between the features and capabilities each provides. There's a good MSFT comparison documentation on it.
Queues vs Topics/Subscriptions - if you need to send a message to a single destination (a command) then queue is simpler. In case a message needs to be broadcasted to multiple receivers (events), topics/subscriptions are your friends.
I am planning a 3-tiered architecture in which I need to track changes to domain objects on the client (a Windows Store app) then send those changes back to the server (an Azure worker-role). I just found out about WCF Data Services which I can run on the client and integrate with Entity Framework Code First on the server. It looks okay but I'm wondering what other tools may also be available.
Are there any alternatives to WCF Data Services for tracking changes in client then sending them to server? If available, I'd like a solution that doesn't require generated DTO classes but instead sends the deltas alone.
Have you considered using rest services?
Im not an AZURE user, but use elsewhere.
Azure rest services docu