Azure Insights can capture and display all the application dependencies calls (db, 3rd party, blobs, queues etc) and it is available in the Azure Portal.
I am looking at the way how to include captured data in the HTTP response headers of HTTP calls to application with enabled Azure Insights tracing.
The use case, it when we run DotNetCore api and call a HTTP method we receive some stats about the number of dependency calls it performed.
Any direction from the community?
Looking at the documentation, but feature I am interested in is not available out-of-the-box.
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?
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.
I'm developing an application following quite closely Feldman Elm SPA example with the API hosted on AWS API Gateway. My problem is the following:
I need to sign my API calls with AWS API Signature v4. It is a less trivial task than I initially thought in Elm:
There is no Elm AWS signature package, so I naturally looked at JS libraries to use via Ports.
Option 1: Use AWS Amplify API that does all the job => But then how to process the result in the most Elm-esque way (ideally with RemoteData).
Option 2: Use a third-party JS library just to sign the request forged by Elm Http.request and send send/process the HTTP request via Elm => So far I found only buggy implementations of AWS Sigv4, I would prefer an official implementation anyway.
In the 2 cases, I'm stuck with the Main Parent / Page Children communication: I can send the request 1) or 2) via Port from the Child. But then, how to can the Child receive the response to his request? Indeed, all responses go into Elm via the same port subscription. Do I need to 'tag' the outgoing requests and then dispatch the response based on the tag? But it will look horrible and won't scale well.
Please note that it is a question about App pattern and architecture. It is not a basic question about Elm Ports (I already successfully call the API from Elm).
Any recommendations or pointers appreciated. Thanks!
Additional info about my setup (following the first comment)
I follow the AWS best practices (scenario #3 Access Resources with API Gateway and Lambda with a User Pool)
Front-end App users are managed by:
Cognito User Pool (signup, sign-in, etc...)
Cognito Identity Pool (map users with IAM role to access AWS resources, including the API Gateway)
Back-end is Serverless: API Gateway + Lambda functions
API Gateway: Lambda proxy integration + Authorization = IAM => this requires the AWS Signature
I don't use API keys because:
I don't want to provide any access to the back-end to unauthenticated users
I need to identify the user from the request headers
I don't want to rely on long-term secrets for authentication on client side
I have a ASP.NET Web API controller that provides a saveAndNew operation.
This class is derived from System.Web.Http.ApiController as expected.
Application Insights is correctly configured using version 2.1.0 of the SDK and the default settings in ApplicationInsights.config.
If a request to the mentioned operation fails - for example with status code 400 - the request is recorded correctly in App Insights.
The problem is that if the operation SUCCEEDS (status code 200) nothing is recorded in Application Insights.
I've used Fiddler to see if the request is made to the App Insights track service and it is not. So the problem is not in the configuration of Application Insights on the Azure portal.
I can't figure out what is preventing ALL requests to my Web API controllers operations from being recorded.
Can anyone help?
You might want to try removing/commenting out TransferRequestHandler in ApplicationInsights.config file.
GitHub issue "REST API app can have all requests filtered out" here states that: "commenting out the one line in the ApplicationInsights.config caused successful requests to start getting logged. Web API 2 project.
<!--<Add>System.Web.Handlers.TransferRequestHandler</Add>-->
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.