I've been investigating what I can do with Google's Secure Data Connector and App Engine.
Is it possible, from an App Engine application, to grab resources inside my corporate intranet without using HTTP(S)?
From what I read in the documentation, the only way to request resources through SDC is by using url_fetch, which is limited to HTTP, right?
You are right that app engine does not let you to other hosts or use sockets directly except through its URLFetch API which is limited to HTTP. However, you are not stuck to traditional ports - you can use it to access ports 80-90, 440-450, and 1024-65535 (as of GAE v1.3.2).
It doesn't seem like this restriction should matter much if you are planning on using SDC - the SDC FAQ seems to indicate that it uses HTTP/HTTPS to connect to resources on your intranet anyway.
Related
We have set up a VPC Serverless access connector, and configured app engine to use this in app.yaml. We have egress_setting: all-traffic set, as we want to access a 3rd party API from a specific IP address. We used the documentation from https://cloud.google.com/appengine/docs/standard/python3/outbound-ip-addresses#static-ip.
Part of our testing is hitting a large set of URLs on app engine and checking the HTTP status. In this testing we noticed a dramatic reduction in the rate of serving requests when using the connector. Since all egress traffic is routed via the connector, my first inclination is to think our applications usage of Google APIs (datastore, cloud storage, Cloud SQL) is being impacted.
The connector is still has the minimum number of instances as active instances, indicating we have not reached the limit of it's performance, and that this is not the bottleneck. However, retesting with the vpc_access_connector removed from app.yaml returns performance to what we previously had.
I've tried enabling Private Google Access on the subnet the connector is linked to, but this has not improved the situation.
I think we may need to add some routing rules that allow us to send the traffic for Google APIs directly to Google's services, and not through the cloud NAT, but I'm unsure as to what rules would be applicable. I see no reason why this is not possible, but I haven't found the right documentation to guide me here.
Is this possible? Is this documented somewhere?
I have previously used
#app.route('/mypage/<int:myvariable>/')
to create rules for what should happen when users land on different urls on my website. I have done this on local machines that have been running on my own virtual servers.
Now I am learning to publish my first web app to Google App Engine. I have heard that I should be using Google Cloud Endpoints instead of the route decorator.
#endpoints...
I've read a few articles about endpoints and some of the benefits of endpoints that they list are:
Endpoints makes it easier to create a web backend for web clients and mobile clients
Endpoints free you from having to write wrappers to handle communication with App Engine
Even if I have read this I can't wrap my head around what this means. I don't understand it. Can you explain in non-technical terms with examples what the advantages of using #endpoints is compared to alternatives? The alternative that I am familiar with is #app.route.
Google Cloud Endpoints can be thought of as a subset of #app.route. They are intended to solve the API backend problem for mobile and javascript clients. They are not intended to serve web pages and other hypermedia. You can use the normal routing methods of your framework of choice to create a web service for your application but Google Cloud Endpoints takes care of a lot of boilerplate for you.
There are a lot of limitations with Google Cloud Endpointsso be sure to familiarize yourself with them before committing. For one, you cannot host Google Cloud Endpoints on a custom domain name. They are only accessible via <app_id>.appspot.com/_ah/api/*
Endpoints makes it easier to create a web backend for web clients and
mobile clients
What this means is that you can create one backend and then iOS, Android and Web-apps (via Javascript for example), can execute your API methods with specific client generated libraries.
This is convenient if you are building a backend that you want to be easily accessed via smartphones or through a web browser.
Endpoints free you from having to write wrappers to handle
communication with App Engine
With Endpoints you can generate client libraries (e.g. Android, iOS, Javascript) that you can then execute your API methods. You don't have to worry about writing a bunch of additional code to do that.
My Opinion:
I have never used Cloud Endpoints to make a web-app but it is very convenient if you are making a mobile app for iOS and Android because you can access your backend with both platforms.
One reason you might want to use Cloud Endpoints for a web-app instead of something else is because of Datastore. Datastore is the way Cloud Endpoints stores data. It is a NoSQL storage method which is kinda tricky to wrap your head around at first if you come from a relational database background, but once you get it, it makes a lot of sense.
I am going to build an API for my mobile app using GAE. I am looking for a way to separate the whole application into separate services, trying out the microservice architecture.
The problem is there seems to be no information about any VPN or private network between GAE apps. Therefore, based on my understanding, when one of the GAE apps sends HTTP requests to other GAE apps in same account, its traffic will be treated as Internet traffic and therefore I will be charged for outbound bandwidth.
Am I correct?
Yes.
App Engine applications/Cloud Platform projects are isolated from each other by default, even if they were created using the same Google account.
Consider looking into Modules (link for Java) to implement individual services of your application.
I want to connect my GAE Java project (Paas) to third party Cloud SQL (DaaS), I just want to know is it possible or not!
Details:
With my basic fundamental knowledge on J2EE I'm doing some hacks onGoogle App Engine (Java) PaaS, since Google cloud-sql for GAE is paid I want connect the GAE to any third party cloud SQL service (DaaS) like nuvola which offers free service for limited time period. Developers pain point is Google Cloud storage/ sql doesn't allow free space for developers unlike other platforms like Parse, kinvey etc will do.
update: URL Fetch API we can do that, I'm not sure it's the right way or not! also URL Fetch API Calls are Outgoing Bandwidth are billable!!
If you want to connect to external systems, the recommended way to integrate with them would be via Web Services.
You have 2 options:
Look out for a Web Service (typical REST with JSON/XML data) for your chosen data service provider in the cloud. You can then integrate your GAE app via URL Fetch API.
There is also a likelihood that your data provider also provides client libraries (Java, Python, etc) which you can easily integrate into your application. That would ease the integration.
App Engine also supports Sockets, but they are currently in Preview and available only for Paid Applications.
I'd like to put a Redis server on Google Compute Engine and speak to it via AppEngine's socket support. The only problem is that there doesn't seem to be a specific firewall rule that says "this AppEngine application can access this host/port and no other".
There are some rules at instance setup time that describe whether the instance has access to task queues, etc, but not the inverse.
So my question is: how can I restrict port access to a Redis service only to a single AppEngine application?
In short you can not. AppEngine is a shared IP space with all the other apps, just like shared hosting. You need to use application level authentication such as OAuth to get the proper restrictions in place.