I have a .net core based micro service architecture.
I chose ocelot as api gateway. My frontend application is vue js based and hosted on nginx container. During a discussion today, I learned that nginx can already be used as a gateway.it was suggested that "you should use nginx for a gateway because you already use for serving frontend, nginx could deploying as a gateway too" I searched the internet to compare the two gateways (I know the main purpose of nginx is not a gateway) but couldn't find any information about their pros and cons like performance,scalability availability etc...
Can someone who uses the 2 technologies share information with me about which one I should choose?
Ocelot is .NET API gateway but cloud agnostic. It has following features as mentioned in article here. It is a free simple Nuget package for simple installations and not too advanced features or performance requirements, but it beautifully does the job always in .net environment, and provides some features also. It is lightweight, fast, scalable and provides routing and authentication also besides all gateway features. On Azure, Azure API management provides these features plus many more advanced gateway features.
NGinx has a open source version and a plus version.
NGINX is a high‑performance, scalable, secure, and reliable web server
and a reverse proxy. NGINX enables all the main web acceleration
techniques for managing HTTP connections and traffic. For many years,
NGINX capabilities such as load balancing, SSL termination, connection
and request policing, static content offload, and content caching have
helped NGINX users to build reliable and fast websites quickly and
efficiently.
NGINX can also act as a secure application gateway, offering a number of specialized built‑in interfaces to pass traffic from users to applications. So, as you see NGinx is much more than just an API gateway. With a server, you can integrate many other services like traffic distribution, policies, monitoring, alerts, notifications, custom configurations etc. Ocelot may have limited performance or configurability for an enterprise grade application.
Nginx is a different software than Ocelot. Kong on NGinx is more popular software for API management gateway and is not .NET specific.
If your company already is using it, and has it already for deployment, you should continue with Nginx.
Ocelot vs Kong vs Azure API management vs Nginx
In normal circumstances, Ocelot may appear better software than Nginx. But Nginx is a full fledged software. Few reasons: a. Your company has a license for Nginx plus already, why use another software for API management. b. Nginx is configurable for high performance, ocelot is not. If you use thread pool is nginx, performance can be tuned. Ten Nginx performance tuning tips.. You can do limited to none such things in Ocelot. It has its own bunch of open issues for a gateway. NGinx plus users will have training as well as team support already available. Nginx will be one API Gateway for all of Your applications (technology independent). Ocelot is technology dependent. Given the pros and cons, your company might already be having a Nginx plus license and a common API for multiple applications, and that's why they might be pushing for it.
First and foremost Nginx and Ocelot are very different software.
using Nginx will eventually be good for your infra as it can be used as an API gateway and it's open-source, secure, and offers many other benefits.
Using Ocelot will have disadvantages in long run. You'll need to handle one more software extra. Why would one waste time on that? and the developer will need to understand both of them.
I suggest you go with Nginx as it's already implemented and do your work
Yes you can use nginx as a gateway. But Apache APISIX is even a better option to use compared to Nginx and Kong. I found this article helpful while searching for a better API Gateway option to use.
https://api7.ai/blog/why-choose-apisix-instead-of-nginx-or-kong/
I am planning to use WSO2 as my API Gateway.
Requirement
We have created .NET Core APIs for our microservices and need to use Gateway for manage APIs.
I am totally confused by whether to use API Manager or WSO2 Micro Gateway or do we need to use both together
Can anyone help me in this regards
WSO2 API Manager is a full life cycle API management solution that also consists of an API Gateway, which serves API requests. However, this API Gateway was not originally designed for the container world. Therefore, this gateway can be a bit bulky for a container.
The solution is the Microgateway, which is designed for the container world. It is very lightweight and container-native. Microgateway can be used with the API manager to manage APIs.
Here[1] you can read more details about when to use each gateway.
[1] https://docs.wso2.com/display/AM260/Overview+of+the+Microgateway
I have been using Zuul as the edge service and API Gateway. Recently I have noticed that Spring Cloud Platform release Spring Cloud Gateway. What is the difference between the two gateways? Why is the Zuul not extended to support the functionalities in S-C-Gateway? What was the driving factor for a new library altogether? When should it be used?
I am the author of spring cloud gateway. Zuul is built on servlet 2.5 (works with 3.x), using blocking APIs. It doesn't support any long lived connections, like websockets.
Gateway is built on Spring Framework 5, Project Reactor and Spring Boot 2 using non-blocking APIs. Websockets are supported and it's a much better developer experience since it's tightly integrated with Spring.
Myself and my architect are designing the architecture for one of our products and he suggested to go with Web Api as a Service Layer (because it's a light weight component).
Straight away I'm thinking how it can be used for non-http based clients and also for external clients. How can we provide the proxy information about our API (in case the API is having a complex type as parameter)?
Please advice whether we can use Web API as Service Layer?
Straight away I'm thinking how it can be used for non-http based clients
Well, it can't. The Web API works only on top of the HTTP protocol. If you need to use some other transport protocols such as UDP you might consider WCF instead.
How can we provide the proxy information about our API
RESTful services do not have the notion of proxy information. They should be documented well for non .NET clients. For .NET clients you could share the contracts (Request/Response Dto) between your server and client application. The client application could then reuse those Dtos which may act as what you call proxy and which is something that exists in the SOAP world but not in the REST world.
I'm developing a server to offer persistence to clients connecting through http. The clients will be based on different technologies: web, iphone and android; that is why I thought of using http in the first place (may be there is a better approach).
In the server I'm using a javaee 6 implementation with EJBs and JPA to achieve my persistence goal and servlets to offer access to the EJBs interfaces to the clients.
The servlets are just dummy proxies, so I'm sure there has to be a framework or a better way of offering my EJB as a service to my clients.
I'm trying to find a way of avoiding all the dummy proxy servlets.
You could implement RESTful Web Services with JAX-RS