google web engine SDK as a local web server? - google-app-engine

I'm thinking of building a dynamic web site using Google web engine Technology, however I would like to use it in a local network without internet . Can I use the Google web engine SDK as a LOCAL SERVER.In other words, is the SDK just for development and testing purposes or it can be used as a server?
Should I worry about long-term use of SDK as a local web server, is there any scalability issues I should be aware of.
Thank you.

You probably could, but there'd be no point.
GAE makes all sorts of tradeoffs which only make sense in terms of the benefits you get by running on Google's infrastructure: for example, the limited querying you can do with the datastore, or the strict timeout on requests.
Plus, the development server is extremely limited in what it can serve, so you'd need to put a proper web server in front of it anyway.
If you're using Python, you can use webapp2 as a standalone WSGI application, although you might be better off going directly for something like Django. I don't know much about serving Java apps directly but I guess you can use Tomcat.

Related

Hosting Web application - best practices

So I have a web application where the Frontend is written in React and the backend is written in NodeJs/NestJs, and are in the stages of deploying the application. I have a Linode server running Ubuntu, and my initial thoughts was to install Docker & Kubernetes (I will need a couple more servers) and then spin up containers for the front and backend, and a separate server hosting the database. Since the requirements are high uptime, scaleability and modularity.
So is this a good way to go about setting up the application? Are there any pros and cons with this setup except pricing because of the amount of servers needed? Or are there any other options available that could be more benefitial?
Thanks in advance.
It depends if you want to make DevOps job or not, and also about the budget you have.
If you really want to stay in control of your clusters, scalability of them and money is not a worry, then kubernetes is a good alternative.
Disclaimer: I don't know Linode and have no idea if there is some GCP compatible services.
For front-end, you said it was react: The hosting service of firebase, here's a tutorial.
And the good news is that you can alternatively use any cloud platform with a storage service like Google Storage, AWS S3 or Azure.
For back-end, I would suggest App Engine or functions, I'm having a great experience using App Engine and is a lot easier to configure than any pods, deployments, ingress and all steps to deploy a kubernetes cluster. I'm not really sure if you can use NestJs with Cloud Functions and all FaaS options.
Also, this suggestion will make you spend a lot less than a whole k8s infrastructure.
But, of course, it depends on your case.

Deploy non-web Java application

I have a relatively small Java app, which I'd like to move over to the Google App Engine. It runs in the console, with no user input needed after the initial startup. I researched a bit on how to deploy it, but all tutorials seem to focus on Java web apps, when I don't really need that. Is it possible to deploy my app if it's not a web app?
App Engine is probably the wrong GCP platform for you - you'd probably be better served just deploying your jar directly onto a Google Compute Engine node. GAE is pretty explicitly oriented around web applications and you'd need to do a bunch of configuration in order to have it work for your use case.
Does your non-web Java app handle web requests? If not, it seems difficult to imagine that you would be able to reach your deployed app and use it for any purpose, once deployed. Your Java app should be able to handle requests, to make deployment worthwhile, and the deployed app useful.
You may find out about how your app should handle requests by reading the How Requests are Handled documentation page.

Google App Engine vs Tomcat

I was able to create the basic 'hello world' program.
When I tried to understand the difference between a cloud and a server I learned that Cloud is where you have an access to virtual instance created exclusively for you and you are free to choose and install software of your choice.Why Google App Engine(GAE) is used widely where as tomcat is not used. What are major differences between GAE and Tomcat?
Cloud is Google Cloud Platform at this case. App Engine is just one of their services.
App Engine is a platform to build your apps on top of it. A Platform As A Service or PaaS. It simplifies the process of building a scalable application, and you should use it when you understand what you really need and understand principles of scalable application.
Tomcat is a Java web container, and there're many alternatives. Google App Engine is using Jetty. You could actually use it with Tomcat by using Flexible VM, though it doesn't make much sense.
App Engine is not about web server, it's a set of services that helps you to build a scalable app. It includes Memcache, Datastore, Task Queue, Images API, deployments tools and versioning, CDN for static files, and most important automatic scale.
Actually you aren't limited to App Engine on Google Cloud Platform. There is more traditional service, like own server in the cloud, called Compute Engine. There you can run your Tomcat or anything else.

Connecting to AppEngine datastore in development via Cloud Datastore API

We are currently running a combined AppEngine / GCE app and thus far have kept all of our datastore access on the AppEngine side of things. Now we are exploring also allowing our GCE instance to make some queries into the (shared) datastore. To start, I'm trying to figure out how to run things locally. What we have so far:
A Go devappserver running
A Go standalone binary that wants to issues queries to the devappserver datastore.
We installed ('go get') google-api-go-client/datastore/v1beta2 so that we can use an API instead of issuing direct HTTP calls. However we are definitely willing to issue direct HTTP calls if this API library won't work in development.
We have service accounts set up (we already access GCS from GCE) but I doubt that's relevant for running locally...
I've seen some docs but they (a) only talk about Python & Java, and (b) discuss connecting to the (standalone) development datastore server, as opposed to the datastore embedded in AppEngine's devappserver (if those are even different?). There is also the following answer here on StackOverflow, but again it discusses connecting to the standalone development datastore server:
How to connect to the local google cloud Datastore db?
Any pointers would be much appreciated!
Ian
Currently this is not possible in the development environment for several reasons. The Google Cloud Datastore tool (gcd.sh) uses the java development server. However when developing go for App Engine you use the python development server, which has different underlying storage. There is a bug to track this issue on the github page.
You can still develop a Google Cloud Datastore application in go however there are many bugs in the current go client library. Unfortunately, the development server does not currently support the JSON API, which the go library uses (see the note at the top of the page).
Update: I wanted to make sure proppy's comment was seen as part of the answer. His suggestion does provide a way to use the protocol version of the API, which is probably more stable than the go client library above. It could also let you use the gcd.sh tool to test this in the development server. You will have to craft the HTTP requests yourself though, and you won't be able to share the data in the datastore between your application and the Cloud Datastore in development. However it is definitely a good workaround and lets you use the Cloud Datastore API, which as it develops will be easier to work with than other workarounds.
From proppy:
Note that you can still use Cloud Datastore Protobuf HTTP API with Go. The protobuf definition is available on GitHub, you can compile it to Go code using the Go protobuf compiler plugin and then send POST HTTP requests to /datastore/{version}/datasets/{datasetId}/{method}.
If the use case from your "GO" app server is straight forward enough, you may want to implement access by using an API call to your GAE service (perhaps extending the service to receive the API calls).
This has the added benefit of only having to make changes in one place if your datastore definitions or functions change.

Hosting/transferring a web site on Google App Engine

I have my website currently hosted on paid server, but i want to transfer it on GAE.
How can i do it? Can anyone please help me in this case.I'd appreciate your help.
Thanks:)
1) First you will have to adapt your website to the GAE framework (python with django or the new Java environment). You can test your work by downloading the SDK of GAE which offer a local server.
2) Then create an account on appengine.google.com and upload your application on something.appspot.com, test it.
3) If you have a domain name, create a google apps account on this domain, and finally bind this domain with your GAE website. Here is the Google doc.
If it is just a static website which does not need server side scripts or a database, then you might want to look into Google Sites instead of Appengine. You can find out more about Sites here: http://www.google.com/sites/help/intl/en/overview.html
If you do have some server side logic going on, you will need to convert it to either python or java and convert your relational database to Google's Data API which does not support the SQL your current database uses. You can read more about the APIs and what is supported with the Data API and tutorials at: http://code.google.com/appengine/
In response to sanorita's comment "Actually, it's generated html and not plain html. and google appengine is for static data... right?":
AppEngine can host static data, but that is far from its intent.
The purpose of AppEngine is to allow developers to easily deploy their dynamic applications on Google's infrastructure. In the end, assuming you have programmed your app in effective ways to handle scaling (basically just noting that writes to the database are expensive, and contention is the root of all evil) you can handle nearly any amount of traffic.

Resources