However, i know API gateway handles traffic north-south and service mesh east-west.
API gateway exposes service to easily consumable, while service mesh manages and controls service inside the network.
Is it still possible to replace API gateway by service mesh Istio?
Please suggest if i am missing anything or if it would be better to use API gateway along with service mesh ?
Yes, API Gateways have an overlap with service mesh in terms of functionality. They may also have an overlap in terms of technology used (e.g., Envoy). Their roles are quite a bit different.
At the boundary of a microservices/cloud-native architecture, an API Gateway provides three main capabilities that a service mesh does not solve to the same degree:
A core functionality of the API Gateway is to provide a stable API interface to clients outside of the boundary. From Chris Richardson’s Microservices Patterns Book, we could paraphrase the “API Gateway pattern” as:
explicitly simplifying the calling of a group of APIs/microservices
emulate a cohesive API for an “application” for a specific set of users, clients, or consumers.
The key here is the API gateway, when it’s implemented, becomes the API for clients as a single entry point to the application architecture
Another important functionality of an API Gateway is that of “governing” what data/requests are allowed into the application architecture and which data/responses are allowed out. This means, the gateway will need deep understanding of the requests coming into the architecture or those requests coming out. For example, a common scenario is Web Application firewalling to prevent SQL injection attacks. Another is “data loss prevention” techniques to prevent SSN or PII to be returned in requests for PCI-DSS/HIPPA/GDPR. The edge is a natural place to help implement these policies
The last major piece of functionality that an API Gateway provides is edge security. This involves challenging users and services that exist outside of the application architecture to provide identity and scope policies so that access to specific services and business functionality can be restricted. This ties into the previous section.
A common example is to be able to tie into OAuth/SSO flows including Open ID Connect. The challenge with these “standards” is that they may not be fully implemented or implemented incorrectly. The API Gateway needs a way to flexibly fit into these environments as well as provide customization
https://blog.christianposta.com/microservices/do-i-need-an-api-gateway-if-i-have-a-service-mesh/