Best way to do API shadowing on GCP - api

We are trying to transition from one microservice to another implementation. In order to properly test it in production, we are looking into shadowing the request in production to new service, and then comparing the result and logging any discrepancy. I am looking for the best tool than can do it out of the box. Previously we managed to do it with nginx, but I prefer an out of the box solution like Google cloud endpoints, or Apigee.

Related

Anyway to setup traefik to feed matomo automatically?

With a self hosted instance like matomo, and a smart edge router like traefik, I was hoping to find some automated solution for analytics via traefik configuration instead of injecting JavaScript into each hosted service on my docker based server.
It seems to me the best way to track usage in the backend, instead of relying on 'the goodness of the browser', especially with ad blockers targeting matomo.
Has anyone tackled this in any fashion?
Yes, it's possible with Log Analytics: https://matomo.org/log-analytics-/
See also: https://github.com/matomo-org/matomo-log-analytics

Sharing user login between Blazor WebServer and ASP.NET Core API

I am building a service-oriented system for personal use (plus few friends may have limited access as well) - the aim is to have a dashboard for controlling my apps running on various machines such as Raspberry Pis (and potentially to be expanded to a VPS or few in future).
The architecture itself is pretty simple. For authentication I want to use AWS Cognito. Services would communicate with WebAPI (and potentially with eachother) using gRPC within a VPN, and dashboard would be served by Blazor server-side (may move to Blazor WASM Hosted model if I find a need for it). Each of the processes may or may not be on the same machine as any other (depending on the purpose). Blazor server may or may not run within VPN (I might want to move it to a separate web hosting later).
I created a simple diagram to visualize it:
The problem comes with authentication. I want to have Blazor server-side and API as a separate processes (for now they're going to run on the same machine, but I may want to move it elsewhere eventually). Ideally authentication should be handled by API, so authentication is client-agnostic, and the API can use it to verify if the logged in user can perform an action - which by itself is simple.
However, I want Blazor server to use and validate that token as well in order to determine what to display to the user. I want to do with the least amount of calls possible - ideally avoiding querying API for every 'should I display it or not?' choice.
I could easily do it by sacrificing possibility to move API elsewhere, and just merge Blazor Server and API Gateway into one project. For my current purpose it would be enough, but it's not an ideal solution, so first I want to look into how could I achieve my original vision.
How could I achieve this (with minimal amount of Blazor server to API queries)?
I was googling for solution a lot, but so far only found either examples of using Blazor server and API as one project, or using client-side calls to API directly.
Thank you good folks in advance.

Implement rate limiting for public facing API deployed in AWS

Our public API is deployed in AWS. They are developed with different tech stacks.
We want to introduce rate limiting (based on IP, access key, etc.) for the API across many services in a generic way.
Less or No ops effort to run
Introducing new services and paths to existing services should not require effort on configuring API gateway
We are considering the following.
AWS API Gateway Looks easy. Not sure adding routes require effort to keep it sync with services.
traefik Looks good. But, we need to run and maintain.
What would be the suggested approach for this? Any better tools/suggestions?
API Gateway with Usage Plans enabled, to enable rate limiting via API key, is going to be the recommendation for a solution on AWS. You can also look into doing something like this in order to support rate-limiting by IP (although if I had to do all that for IP rate-limiting I'd probably look hard at third-party products like traefik).
As mentioned in the comments, you can configure catch-all routes in API Gateway so that you don't have to modify the configuration every time you add a new route.

Does Openshift Origin 1.1 REST API allow to create new applications based on templates?

We are developing a custom console to manage development environments. We have several application templates preloaded in openshift, and whenever a developer wants to create a new environment, we would need to tell openshift (via REST API) to create a new application based on one of those templates (oc new-app template).
I can't find anything in the REST API specification. Is there any alternative way to do this?
Thanks
There is no single API that today creates all of that in one go. The reason is that the create flow is intended to span multiple disjoint API servers (today, Kube and OpenShift resources can be created at once, and in the future, individual Kube extensions). We wanted to preserve the possibility that a client was authenticated to each individual API group. However, it makes it harder to write easy clients like this, so it is something we plan on adding.
Today the flow from the CLI and WebUI is:
Fetch the template
Invoke the POST /processedtemplates endpoint
For each "object" returned invoke the right create call.

Ways to restrict WCF Service so only our apps can access it

I have a public WCF Service.
I have a WPF Desktop app & a silverlight app. My apps does not have any login requirements.
I want to make it difficult for another developer / website to make use of my service.
What's the best way to restrict access to my service? Use SSL and have the desktop / silverlight app store a token inside of it?
Yes, having a token / certificate be part of your installation is probably the most efficient way to make sure only computers with your own software will be able to access the service.
Also: do not publish the WSDL, e.g. turn off all metadata endpoints and "HTTP Get URL" and so on - don't publish your presence to everyone surfing around! ;-)
In addition, your app could also send some specific headers - although those are fairly easy to find and decipher.
And last but not least: you could come up with your own whacky binding, e.g. have some oddball combination, possibly your own serializer or message formatter. That's taking it quite far already, but it would definitely be possible to put up some hurdles there, too.