ASP.NET Core Api-Gateway middleware
I am new to API gateways and have a question of understanding. I try too put a series of (micro)services behind an endpoint.
For this purpose, I have set up an ASP.NET Core Application and added the package ThreeMammals Ocelot. With the help of documentation I have configured the Up- and Downstreams. So far, so good.
The client makes a request to http://mygateway:4242/s1/{api} and, for example, get a JSON or XML response from Service1, as expected.
Same behavior for http://mygateway:4242/s2/{api} with also the expected result!
My understanding problem is with Service3. When I send a request to http://mygateway/s3/, I get the index.html as response.
The index.html itself requires the CSS-File 'xyz.css' via link-tag and forces the client to load the file.
<head>
<link rel="stylesheet" type="text/css" href="xyz.css">
</head>
The request URL the client send to "mygateway" in this case is http://mygateway:4242/xyz.css and not http://mygateway:4242/s3/xyz.css and so the respone is a 404 not found, since the "mygateway" knows nothing about a "xyz.css"
How can I fix this routing(?) issue?
Is it possible to solve this problem with ocelot middleware? Or do I need something else for the service (Service3) with the SinglePageApplication (SPA)?
Maybe is it simply not possible or wrong to place the SPA behind the gateway? I hope you can give me some tips to get access to a SPA or MVC website behind a gateway.
Thanks iBot
UPATE: Enclosed the code of index.html. I think that's straight forward.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Title</title>
<base href="/" />
<link rel="stylesheet" type="text/css" href="dist/xyz.css">
</head>
<body>
<div id="appContainer"></div>
<script src="dist/xyz.js" asp-append-version="true"></script>
</body>
</html>
Answer
Your architecture design is wrong!
First, let's find out what this the API Gateway.
An API Gateway is programming that sits in front of an application programming interface (API) and acts as a single point of entry for a defined group of microservices.
A major benefit of using API gateways is that they allow developers to encapsulate the internal structure of an application in multiple ways, depending upon use case. This is because, in addition to accommodating direct requests, gateways can be used to invoke multiple back-end services and aggregate the results.
Ok, the name "API Gateway" shows us that it is mostly intended for API services! SPA or MVC applications are not back-end services. You should not put your front-end applications behind the api gateway.
In general, your architecture should look like this:
An API gateway is the single entry point for all clients. SPA is client of your services and should call it through API Gateway. If your application has multiple client apps, that can be a primary pivot when identifying the multiple API Gateways types, so that you can have a different facade for the needs of each client app. This case is a pattern named “Backend for Frontend” (BFF) where each API Gateway can provide a different API tailored for each client app type.
What if you don't want to build a proper architecture?
- You can configure redirect. It is something like to specify a default service of API gateway. Then all clients that go to
http://mygateway:4242/will redirected tohttp://mygateway:4242/s3/ - Ocelot allows Middleware Injection. So, you can inject your custom middleware where you will check which request and where to redirect it.
- Use CDN to store all css and other content.
- Inline css into html files.