DEV Community


An API Gateway

Afshar Mohebi
A work-life balance lover developer who is passionate about startups while trying to keep updated with coding trends.
・2 min read

It's years that microservice is a popular solution in distributed computing. People are now considering microservice as a response to a couple of issues in software engineering world. This includes performance, scaling and complexity. Major platforms include a good level of microservice support. This support is divided into few parts. One of this parts is API Gateway. This feature acts a distribution point. Every request is received at the gateway and the gateway distributes it to other microservice nodes based on different criterion.


Many folks have tried their chance on creating an API gateway in their favorite platform. I am no exception as today I created my own API gateway called Valdis. It is based on .Net 5. Valdis is a play on words validation and distribution. As its name implies, it validates the requests and then distributes them to existing microservice nodes. The way it works is not based on redirection, instead, it sends the request to the node internally, receives the answer and then sends it back to the original caller finally.

How it works?

Navigation is based on the URL. There is a setting which indicates requests should be sent to what hosts. It checks if the URL is starting with a specific string. Hosts can be a list. Which host will be directed to is selected based on a random number. It can be imagined as a load balancing mechanism. See settings a clue:

    "Providers": [
"Starting": "/warehouse",
"Hosts": [
"Starting": "/v1/common",
"Hosts": [
Enter fullscreen mode Exit fullscreen mode

Next step

I'm going to add token validation based on JWT on next step. Also a good logging is desired.

Discussion (2)

davidkroell profile image
David Kröll

Pretty decent project!
What happens if a host from your configuration is down? Is this case handled already?

afsharm profile image
Afshar Mohebi Author

In this step, what has returned from the down host is returned, will be returned to the original client. For example if a 500 error occurs or if a bad request happens, all the HTTP status, body and header is exactly repeated to the original client.

But by your good hint, I am inspired to ban the down host temporairly or permanently. So do not send requests to hosts which are down. The definition of down can be configurable. For example a timeout error and all 500 family error can be considered down and all other error can be consider repeatable actions.