I'm new to Google Cloud and trying to understand the relationship between a Google Cloud endpoint and a back-end app on App Engine.
It looks like when I deploy my application (gcloud app deploy) I get a URL that looks something like https://my-service-dot-my-app#appspot.com/path/operation/etc. Is this URL going through the cloud endpoint, or right to the container?
When I call the service in this way I don't see any traffic to the cloud endpoint. In fact when I try to access the service using what I think is the cloud endpoint it just gives me a 404 (https://my-app#appspot.com/path/operation/etc). Why can't I access with the endpoint? Permissions?
My initial thought was that the endpoint was something separate that routes traffic to the back-end. However, when I do something like change the security configuration in openapi.yaml and just redeploy the endpoint definition (gcloud endpoints services deploy openapi.yaml), this does not seem to actually have any effect.
For example, the initial deployment had Firebase security. I removed it and redeployed the endpoint definition but security remains on when calling the service. Seems I have to redeploy the back-end to disable security.
Any insight would be appreciated.
Cloud Endpoint is a security layer in front of your API. It acts as a proxy and performs security checks (based on API Key, OAuth, SAML,...) and routing to the correct Endpoint. The endpoint definition is based on OpenAPI 2 (not 3, be careful!). There is new advance feature like rate limit and soon billing.
Initially integrated to AppEngine, this product has been open sourced and can be deployed on Cloud Run, Cloud Function and on GKE/Kubernetes. A similar paid and more powerful product is Apigee.
I wrote an article for using Endpoint deployed on Cloud Run, with API Key security and which route requests to Cloud Run, Cloud Function and App Engine.
Cloud Endpoint also offers a developer portal to allow your customer, prodiver and developer to view your API specification and to test it dynamically on line.
I hope these elements provide you a better overview of Cloud Endpoint to abstract your underlying API deployment.
I believe we need to address a few points before providing the correct way forward:
For your first question:
Is this URL going through the cloud endpoint, or right to the container?
Deploying an application to App Engine will generate an #appspot URL for the app. This URL is used to access the application directly, and it will remain available to the internet unless you enable Cloud IAP, or set any other restrictions to the service.
For your second question:
Why can't I access with the endpoint?
If you are referring to the https://my-app#appspot.com/path/operation/etc, there can be a lot of reasons for it to not work, it will depend on which step of the setup process you are.
Normally for setting up Cloud Endpoints with OpenAPI, with an App Engine backend, you need to limit access to the #appspot URL, but also deploy an Extensible Service Proxy (ESP) to Cloud Run to access it later.
Conclusion:
Now, for actually achieving this setup, I suggest you follow the Getting Started with Endpoints for App Engine standard environment.
As per the guide, the following is the full task list required to set Endpoints for an App Engine Standard backend, using Cloud Endpoints:
1 - Configure IAP to secure your app.
2 - Deploy the ESP container to Cloud Run.
3 - Create an OpenAPI document that describes your API, and configure
the routes to your App Engine.
4 - Deploy the OpenAPI document to create a managed service.
5 - Configure ESP so it can find the configuration for your service.
Keep in mind that once you set up the ESP configuration, any calls will need to go through the [YOUR-GATEWAY-NAME].a.run.app.
If you happen to be stuck in any particular step, please provide what you have done so far.
I hope this helps.
Is this URL going through the cloud endpoint, or right to the container?
App engines are container based deployments on Google's infrastructure. The url are created when you deploy it and please note its not API.
When I call the service in this way I don't see any traffic to the cloud endpoint
I dont think a Cloud Endpoint is created by default
One way to check if a Cloud Endpoint is created is to check if its API is enabled in your project or a service account is created in IAM page
To configure a Cloud Endpoint for App engine, following this procedure
I am deploying a React.js front-end (built with create-react-app) and a back-end with a CRUD API that connects to Cloud SQL.
Is this a good way?
React.js front-end is a default service.
Back-end API is backend service
I'm familiar with deploying to Heroku, which had front-end and back-end on different ports. Would that work for App Engine?
This is all in Node.js.
I don't see any issues with the described design.
To get you on track you can take a look in Stack Overflow thread How to deploy create-react-app to Google Cloud or the following tutorial.
You can run applications on different ports with setting port forwarding in your app.yaml file.
The design pattern is good.
You only need to create a dispatch.yaml file which is only one per project.
Your dispatch.yaml file would look something like this:
dispatch:
- url: "*/backend/*"
service: backend
Then your frontend at project-id.appspot.com will simply make requests to https:/project-id.appspot.com/backend/ *, and these requests will be redirected to the API service.
Using the App Engine Flexible Environment, I'm preparing to deploy an Angular 4 client and am looking into Cloud Endpoints to handle my node.js/express microservices as it seems to simplify securing and authenticating endpoint requests, and I wanted to clarify a few things:
Do I use cloud-endpoints as an API Gateway which routes requests to the individual microservice backends or are the microservices supposed to be built as individual endpoints-apps themselves?
Do I host the Angular 4 app statically (server agnostic), and make endpoint requests directly to the Gateway/microservice from the ng client, or is the app hosted through a server framework (e.g. node.js/express) which then passes on the request along to the Gateway/microservice
Endpoints is an API gateway, but it currently only routes to a single backend. On Flex, it's whatever app you deploy. The Endpoints proxy sits in front of your backend, transparently to the client, and the client requests will pass through the gateway. See the docs for how to set up your Flexible environment.
In conjunction with a dispatch.yaml directive to handle routing, you can use GCE as a gateway to multiple microservices running as services in a given project.
You can call the services directly or proxy through a server.
Looking for some insight/advice.
I'm creating an app where I want to expose an API that will be used by 3rd parties as well as my own web and mobile apps. Looking at the MEAN stack to do this. My thinking is that I should create 2 apps:
Express-based API app that talks to the MongoDB. No UI, just RESTful endpoints.
Angular-based web app with the UI. Does this app require Express? This app will hit the API endpoints to get/put data to the backend. Can Angular run on its own or does it need Express/Node. My thoughts were for Angular to handle the UI page routing and Express to handle the API routes.
Also, in the mix, is an iOS mobile app and Android app. These will also hit the API for data.
My background is heavy Java/Spring/Hibernate/Spring Boot and .Net. So, explaining MEAN stack as it relates to Java technology/frameworks would help!
I have a rest service that I need to use in a browser web application using a JS MVC client framework like Backbone or Angular. But I need to ensure that my rest services are not exposed or anyone else may not be able to use my rest service to build apps on any device/client. Earlier I thought of protecting my web service using authentication credentials and hiding it behind a proxy and let the proxy serve html instead of service.
But I would like to know how can I secure my web service if I have to use it directly from front-end using ajax calls.