Tyk VS krakend-ce

Tyk: An open-source API Gateway that is fast and scalable, running on either its own standalone server or alongside your existing nginx installation.

We're a friendly bunch at https://github.com/TykTechnologies/tyk - I'll gladly pick up onboarding contributors for some meaningful tasks, if you'd like to ease into it. Lots of tech debt to address, so it's more maintenance work, testing, introducing DDD, etc.

Traditional way to try an open-source project Tyk is an open source API gateway project. Organizations can control access to the gateway and protect the security of enterprises and organizations. To start with, I chose the traditional way, using docker-compose to install it, which requires the Git and Docker environment on the computer.

Amazon API Gateway AWS provides fully managed service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket where developers can create APIs that access AWS or other web services, as well as data stored in the AWS Cloud. Kong API Gateway Kong Gateway is an open-source, lightweight API gateway optimized for microservices, delivering unparalleled latency performance and scalability. If you just want the basics, this option will work for you. It is scalable easily horizontally by adding more nodes. It supports large and variable workloads with very low latency. Other API Gateways Apigee API Gateway MuleSoft Tyk.io Akana SwaggerHub Azure API Gateway Express API Gateway Karken D Choosing the right API gateway Some of the common baseline for evaluation criteria include simplicity, open-source vs propriety, scalability & flexibility, security, features, community, administrative (support, monitoring & deployment), environment provisioning(installation, configuration, hosting offering), pricing, and documentation. API Composition / Aggregation Some API requests in API Gateway map directly to single service API which can be served by routing request to the corresponding microservice. However, in the case of complex API operations that requires results from several microservices can be served by API composition/aggregation (a scatter-gather mechanism). In case of dependency of one another service where synchronous communication is required, the chained composition pattern has to be followed. The composition layer has to support a significant portion of ESB/integration capabilities such as transformations, orchestration, resiliency, and stability patterns. A root container is deployed with the special distributor and aggregator functionalities (or microservices). The distributor is responsible for breaking down into granular tasks and distributing those tasks to microservice instances. The aggregator is responsible for aggregating the results derived by business workflow from composed microservice. API Gateway and Aggregation API gateway with added features results in overambitious gateways that encourage designs that continue to be difficult to test and deploy. It is highly recommended to avoid aggregation and data transformation in the API Gateway. Domain smarts are better suited to be done in application code that follows the defined software development practices. Netflix API Gateway, Zuul 2 removed a lot of the business logic from Gateway that they had in Zuul to origin systems. For more details, refer here. Service Mesh and API Gateway Service mesh in microservices is a configurable network infrastructure layer that handles interprocess communication. This is akin to what is often termed as sidecar proxy or sidecar gateway. It provides a lot of functionalities such as:

KrakenD: A high-performance open-source API Gateway. It helps application developers release features quickly by eliminating all the complexities of SOA architectures while offering a unique performance.

This is my first foray into NGINX, and it seems my desired use-case is a bit different/left field. We're attempting to utilize NGINXaaS (Azure PaaS) to act as an API Gateway for some of our on-premise APIs. We were trailing KrakenD prior for this, but are moving toward NGINX as there's a desire to move everything PaaS (where appropriate). Our current KrakenD instance is configured to host a different set of URI than what the backend is configured for, IE:

Check what configuration language (JSON/Yaml) and style (Declarative/Imperative) chosen API Gateway support. It is not so crucial but sometimes you might ask: Does it have a user-friendly GUI and drag&drop easy config option? Some open-source projects like Tyk, Krakend.io, and Apache APISIX have built-in no-code possibly visual editing dashboards. You can even import all your APIs descriptions from a JSON.

KrakenD and Lura https://github.com/krakendio/krakend-ce https://github.com/luraproject/lura

I was trying to look up the license for that project and the repo linked from the footer of their website is https://github.com/krakendio/krakend-ce#readme (Apache 2), but because I just did a web search for krakend there is also https://github.com/luraproject/lura#readme which says it's from the Linux Foundation (also Apache 2)

Is KrakenD some kind of generic term, or does that project just have a complex history?

https://github.com/krakendio/krakend-ce api gateway built using lura