I have Google Run containers serving gRPC services. I'd like to build out a front end using web gRPC on Firebase. I am exploring the usage of Google API Gateway as a proxy between web gRPC and proper gRPC.
I am looking at this guide: https://cloud.google.com/api-gateway/docs/get-started-cloud-run-grpc which doesn't mention web, but I know the gateway is based off Envoy which is used for this purpose quite often. I am wondering if someone has a definitive answer or whether I need to deploy Envoy as a service on Cloud Run by hand to serve as a proxy.
Yes, API Gateway supports gRPC-web. API gateway runs ESP-V2, which is built on top of ESP. The original ESP has added the support for grpc-web which is shown in this GitHub link. And it still exists in ESP V2 as we can confirm from this link
API Gateway allows clients to use HTTP/JSON to communicate with gRPC service. You can look at this link and see if it helps your use case.
Related
I would like to ask everyone about the limitation of these services
Cloud Endpoint and API Gateway (Beta) on the Google Cloud Platform.
These services are support WebSocket protocol?
Because I can't find the docs official reference about it.
As I know the ESP is already suport WebSocket
https://github.com/cloudendpoints/esp/blob/master/start_esp/start_esp.py#L535
But I still confused. It's possible to write the rule/config on OpenAPI docs (swagger 2) ?
I try to find the apporach to do it. many people suggest to use another tools for make it such as asyncapi.
So the Cloud Endpoints and API Gateway (Beta) are support websocket protocol?
At the moment, Google Cloud Endpoints and API Gateway, both do not support Websockets.
The flag --enable_websocket seems to be deprecated and doesn't have any effect over Cloud Endpoints.
I have created a Feature Request in Google Public Issue Tracker for the support of Websockets in API Gateway. Please track the feature request for all the future updates regarding the support of Websockets.
I am currently building a rest api, for this I am using Google Cloud API Gateway and Google Cloud Run. I've been looking at all the google cloud documentation and researching elsewhere and I can't find how to add a custom domain to an API gateway instance. The funny thing is that there is more documentation for Google Cloud endpoints, I could find how to do it with endpoints but it does not apply to my use case.
I have 10 instances of google cloud run each one running a microservice respectively and I want to join everything in a single domain and add support with openapi, but I have failed in the attempt.
In any case, if someone has managed to customize the domain of an api gateway instance, I would appreciate if you could guide me, greetings.
For the beta release, custom domain names are not supported on GCP for API Gateway. Since it is still beta as of today, if you want to use a custom domain, you could use Cloud Endpoints in Cloud Run or you could even look into using Microservices in App Engine.
I'm building an app and the idea is to go serverless.
I'm looking mainly at AWS and GCP (Google Cloud Platform), and as AWS costs are a bit obscure (at least for me), and there is no way to ensure not being billed, I'm going with GCP.
For the "server" part of the app, I would like to build an API on GCP as I could do with AWS API Gateway, but I couldn't find any matching product for that.
The closer one was Google Cloud Endpoint, but it seems to have a very different concept from AWS API Gateway. I've watched some videos about it (for example https://www.youtube.com/watch?v=bR9hEyZ9774), but still can't get the idea behind it or if it fits my needs.
Could someone please help clarify which GCP product would be suitable for creating an API and how it compares to AWS API Gateway?
Some link with info/example on how to do it would be really appreciated.
Google Product Manager here.
We don't have an exact analog for AWS API Gateway.
You're right about Cloud Endpoints. It's a bit of a different architecture than AWS uses -- it's a sidecar proxy that gets deployed with the backend. That's different than API Gateway, which is a fully managed proxy deployed in front of your backends.
If you are deploying in App Engine Flexible environments: good news! The Endpoints Proxy can be deployed as part of your deployment. It can do things similar to AWS API Gateway (API key validation, JWT validation, rate limiting).
We are working on some plans to allow for the proxy to be used in other places (Cloud Functions and the newer App Engine Standard runtimes).
And, finally: on our older App Engine Java and Python runtimes, we have API Frameworks that provide the same functionality. Those frameworks do the same thing as the proxy, but get expressed as code annotations and built into your app. We're moving away from the framework model in favor of the proxy model.
An example of springboot project with google cloud app engine can be found here-https://github.com/ashishkeshu/googlecloud-springboot
I am developing a web application for image upload and retrieval with AWS cloud services using a micro service architecture.
I am new to AWS and micro service architecture, please help me map the components of the architecture to AWS components.
Do i consider each micro service to run on one EC2 instance with auto scaling and load balancing?
Or do I run each micro service on one EC2 cluster?
If i put my static html files in an S3, how can i call database methods to load the html pages with content?
Is it by calling am API gateway from the client?
I have searched the web, but was unable to find a tutorial which implements multiple services as micro services using AWS EC2 / ECS.
Please help me figure out how to map my requirements and if there are any tutorials on implementing a similar app, will be very helpful.
Thank you in advance! :)
In short, you could use the serverless architecture i.e (with AWS's APIGateway and Lambda services) to build robust micro service based web applications.
Since you said that you were new to micro services architecture, I am listing down the best approaches.
Frontend/client
Single page applications(SPA) work well in the front-end and as they are a static site, they could be easily deployed to S3. This is the most cost efficient approach for SPAs. Here is a video deploying SPA on S3. This video will guide you through step by step instructions for deploying your SPA.
In case, you use react and redux in the front end, check out these steps for deploying react app to S3.
Backend
AWS EC2 is a good option. But there are many more alternatives available. As you said, you were new to backend, setting up EC2, VPC's and Elastic-ip is a little difficult process.
Nowadays, SPA's cover a lot of business logic, routing, etc., We need our backend only as API's for performing CRUD operations with database. I would like to suggest a bleeding edge technology called serverless. Here is the tutorial for launching your backend within 5 minutes. AWS lambda is a service that is called as function as service. You can build your backend using AWS lambda + API gateway + DynamoDB.
For eg: say you want to register some details in backend, you will POST all the data from client to your backend with url and proper path. In AWS lambda, you write your logic for POST as a function, which contains the logic to parse the data from request and send to dynamoDB. Now, this function can be exposed to world by connecting this function with API gateway( an another service in AWS). At the end we get an API, which can be used in your angular 2 APP. SO, on invoking the POST, angular 2 -> API gateway -> Lambda(extract request and send to DB) -> dynamoDB.
Benefits of using serverless compared to EC2.
You don't need to manage your server(EC2) from updating the new security patch to auto-scaling, everything is taken care by lambda. Serverless is a fully managed service.
You only pay when your lambda functions are invoked. On the contrast, even though your web app doesn't receive traffic for a given day, you have to pay the day-tariff for the given day.
Here is my github repo which could be a boiler plate for reactJS + Serverless + graphQL web app.
Having said, try serverless when compared to traditional backend approach. Any questions on this would be welcomed.
I was thinking of using my own custom api gateway running on a separate box using nginx.
Is there any way in which the WSO2 API Manager can integrate to my api gateway?
In case there isn't, wanted to know if there's the possibility to run WSO2 API Manager without (or disabling) the API Gateway and if you could tell me which WSO2 API Manager's features would be unavailable.
Currently there's no way of replacing the gateway since we do the authentication, throttling, etc using synapse handlers. Here I am not sure about your use case of using nginx but what you can do is you can use nginx endpoint when you create the API or on the other way around you can route nginx traffic to API Gateway (you need to fix the API endpoints appearing in the API manager store view to point to nginx). Basically API layer need to be on top of service layer.
I 'm looking for a tool to host and publish APIs documentation so
that users of the api can browse it and test it right from the
documentation web page
If i got it correctly, you need a API store only to host your APIs.You can try enterprise store The documentation can be found here