- Major branching points in your code
- When errors or unexpected values are encountered
- Any IO operations: calling database / stored proc or make http request
- Significant domain events
- Request failures and retries
- Beginning and end of time-consuming operations
using System.Security.Cryptography; | |
using System.Text; | |
namespace Lemonway.TransactionService.Application | |
{ | |
public static class AesEncryptionHelper | |
{ | |
public static string Encrypt(string payload, string secret) | |
{ | |
byte[] iv = new byte[16]; |
// Place your key bindings in this file to override the defaultsauto[] | |
[ | |
{ | |
"key": "ctrl+t", | |
"command": "workbench.action.togglePanel" | |
}, | |
{ | |
"key": "ctrl+shift+f4", | |
"command": "workbench.action.closeOtherEditors" | |
}, |
Your HTML page (the host page) has an Iframe. The Iframe source is on other domain, so you will have to use the window.postMessage()
for cross-origin communication.
But this communication is only in 1 direction (The Iframe can inform the Host or the Host can inform the Iframe)
This article shows you how to make the Request/Reply communication using postMessage()
and MessageChannel
combination.
The article did not show you how to add a timeout to the communication, so the Iframe might wait forever if the Host did not response.
I will resume the technique by some codes snippets and at the same time add the missing timeout implementation.
When designing or learning about APIs or microservices, it's crucial to consider error handling. API's designer often categorize errors into "Technical" and "Functional" (or "Business") errors. However, this distinction may not make sense:
- An API/micro-service should alway return ONLY "Functional" (or "Business") errors.
- The API/micro-service migh crash while processing a consumer's request and so the consumer will naturally get a technical error. But the API/micro-service should not deliberately return a "Technical" error for consumer.
We will explore the distinction between "real technical errors" and "fake technical errors," which are initially technical but later manifest as business errors, thus becoming "fake technical errors."
- HTTP 404 Business error (or Fake technical error)
Read Part 1: MediatR vs MassTransit Mediator - Differences
The MassTransit Mediator implementation is more powerful than MediatR implementation, but also more complicate to use. Unit Testing a MassTransit Consumer is not a nice experience.
In this article I will propose some techniques to simplify the MassTransit Consumer and to make them look as straight forward as a MediatR handler.
We will study a very common use case (the most common use case which I can think of):
In a ASP.NET Web application. You don't need mediator
- If you prefers to make controlers depends directly to the Application Codes instead of indirectly via the Mediator.
- If you prefers to make a normal ASP.NET Web Application instead of a Mediator Application
Frankly it is not a Bad choice, no need to use a Mediator framework or make a Mediator Application just because everyone did.. Though, There are benefits in making a Mediator Application:
- Event sourcing (Messages broadcast), CQS pattern..
- Decouple the Controler (presentation) from Application codes, so that you could swap the presentation technology. For eg, if you make a "MassTransit" application, then you can swap the presentation layer to Mediator or RabbitMQ, or Grpc.. => you are not to be sticked with or limited by ASP.NET presentation => but rather sticked with and limited by your mediator framework!
using MassTransit; | |
using MassTransit.Testing; | |
using Microsoft.Extensions.DependencyInjection; | |
using Moq; | |
using Moq.AutoMock; | |
using System.Threading.Tasks; | |
using Xunit; | |
namespace HiepTest; |
apiVersion: v1 | |
kind: ConfigMap | |
metadata: | |
name: fluentd-es-config | |
namespace: kube-system | |
labels: | |
addonmanager.kubernetes.io/mode: Reconcile | |
k8s-app: fluentd-es | |
kubernetes.io/minikube-addons: efk | |
data: |
In this challenge, you will have to create a WebService and test it. You will then have to publish your code sources to Github, and send the link to it@lemonway.com with your CV in attachment.
- Feel free to use any library / framework or copy/paste codes of others with respect of the author's license. Please list the used libraries / code snippets in your README.md file.
- There is no time limit.
Open Visual Studio (the latest Community Edition is recommended).
Create a ASP.NET SOAP WebService (not a WCF WebService or a Restful WebService) with the following Web Methods: