Author: Vinny Panne

Posted on

Sending Mail With Golang

Previously I published a Java code example using the low level Mail API to send a message to the registered admins of an application. Here’s sample code for a Golang application to send mail to app admins. C stands for an appengine.Context reference.

If you want to send mail to an arbitrary user, and not an admin, you can uncomment the To line and change SendToAdmins() to Send().

application_id := appengine.AppID(c)
separation_point := strings.Index(application_id, ":")
if separation_point > -1 {
    application_id = application_id[separation_point:]
}

//Create the message struct
msg := &mail.Message{
    Sender:  "donotreply@" + application_id + ".appspotmail.com",
    //To:    []string{"To-User <[email protected]>"},
    Subject: subject,
    Body:    email_body,
}
c.Infof("Sending message: %v", msg)

//Send an email to admins
err := mail.SendToAdmins(c, msg)
if err != nil {
    c.Errorf("Unable to send email: %v", err)
}
Posted on

Writing To The Blobstore Using The Files API

A short code snippet showing how to write data to the Blobstore using the experimental Files API.

FileService file_service = FileServiceFactory.getFileService();
AppEngineFile file = file_service.createNewBlobFile(mime_type, filename);
FileWriteChannel write_channel = file_service.openWriteChannel(file, true);
ByteBuffer buffer = ByteBuffer.wrap(byte_array);
write_channel.write(buffer);
write_channel.closeFinally();

 

Posted on

TaskTooLargeError

Google App Engine has an upper limit on how much data you can put into a task – a maximum of 100 KB. This includes everything within an individual task such as parameters, payload, the request URL, etc.

To get around this error, store any large pieces of information within an entity in the datastore. You can then pass the entity’s ID as a task parameter and pull out the entity’s data during task processing.

Posted on

Geolocation With App Engine

One of the best parts of hosting with App Engine is the free geolocation service it provides. Every incoming request has special AppEngine location headers added to it.

For instance, here’s how to find out the user’s city (req is the servlet’s HttpServletRequest object):

 String city = req.getHeader("X-AppEngine-City");

Other geolocation information is available as well: the user’s country (X-AppEngine-Country), the region of that country (X-AppEngine-Region), and the nearest city’s latitude and longitude (X-AppEngine-CityLatLong).

Posted on

Mapping Favicon.ico In A Golang Application

One of the most annoying issues about configuring a Go based app is correctly mapping every file to its proper path.

For instance, beginners at Go frequently declare their first handler like so:

http.HandleFunc("/", handler)

And declare a simple app.yaml, similar to the one below:

application: application_id
version: 1
runtime: go
api_version: go1

handlers:
- url: /.*
  script: _go_app

Unfortunately this will cause all requests to be routed to your Go application code, even if you have static files in your application’s root directory.

To map favicon.ico (or any static file in the app’s root directory) so AppEngine will serve it, replace the handlers section in app.yaml to properly indicate where it is and the url it maps to:

handlers:
- url: /favicon\.ico
  static_files: favicon.ico
  upload: favicon\.ico
- url: /.*
  script: _go_app
Posted on

Sending Mail With The Java Low Level API

Code example on how to send mail using the Java low level API. This code generates the appropriate From address based on your application’s ID.

MailService.Message message = new MailService.Message();
message.setSubject(subject);
message.setTextBody(body);
String application_id = SystemProperty.applicationId.get();
String sender = "donotreply@" + application_id + ".appspotmail.com";
message.setSender(sender);
MailServiceFactory.getMailService().sendToAdmins(message);
Posted on

Google Compute Engine

Google’s Compute Engine just released into General Availability, and I’ve been testing it out the last couple of days.

The one thing that blows me away is how reliably fast even the low-end instances are. I provisioned and set up a f1-micro instance – it runs great and quite consistently. That’s in sharp contrast to Amazon’s micro instance which is limited to “bursty” processing; there are spikes where processing goes quickly, then the CPU gets throttled and the instance grinds to a near-halt.

I’m considering building a mail app on top of GCE – so far, everything looks great. GCE even allows inbound SMTP connections (although unfortunately no outbound SMTP connections).

Posted on

Configuring Nameservers For .IO Domains

I recently purchased a .IO domain name from nic.io, and immediately set about configuring it for Google App Engine. I was surprised to find out that nic.io doesn’t provide customizable DNS – you can’t set CNAMES, TXT or MX records. The only options provided are to set your own nameservers, or forward the domain to another web site.

Fortunately I have a spare GoDaddy account, and they offer free DNS services even for domains not hosted with them. Here’s how I configured nameservers for my .IO domain:

First, go to DNS Manager:

Select Off-site > Add Off-site:

Type in your .IO domain:

Copy the provided nameservers to your clipboard, and press finish:

Paste the nameservers into the nic.io administration page:

Wait 24 hours for the changes to propagate, and you’re done!

Posted on

Optimizing Datastore Use

Google App Engine’s datastore is one of the most underrated parts of the service. Having a relatively cheap (in some cases free) use of a fast, reliable NoSQL store is a terrific deal, especially since most developers are only experienced with SQL databases.

With that said the App Engine datastore can get expensive quickly, especially if it’s being used inefficiently. One of my favorite illustrations of this point is this article. Here’s what I do to optimize my datastore use:

  1. Use .setUnindexedProperty. To set a property on an Entity you call entity.setProperty(key, value). But in the background App Engine is building an index (perhaps multiple indexes) to allow searches on that property. These index builds can get expensive very quickly. If you don’t need to search on a property, use setUnindexedProperty. This informs App Engine that the application will not be searching on that property, so don’t build an index.
  2. Cache data in memcache. Whenever you make a datastore request, copy the returned results into memcache. Then if you need to make the same request, try pulling the data from memcache before querying the datastore again. Memcache use is free so access it before the datastore. Some datastore abstractions – such as Objectify – do this automatically.
  3. If this is a high-traffic app, consider using a backend. A high-memory backend can hold a large amount of data in RAM, and you can transfer data to/from other instances by using URLFetch. As a bonus this technique can be faster than querying entities from the datastore.
  4. Turn off AppStats. If you have AppStats enabled, turn if off for some speed gains. AppStats stores its data in memcache which may cause some of your data to be evicted, causing increased datastore queries and an increased datastore bill.
Posted on

Google Drive: Creating a folder

Today I answered a question about how to create a folder in Google Drive . The answer is simple: Google Drive considers a folder to be simply another file, so to create a folder you use the same API call as creating a file, except that you pass in a MIME type of application/vnd.google-apps.folder.

It’s a pretty straightforward answer, but it started me thinking about the nature of folders and Google. It’s interesting that Google Drive supports folders at all, considering that another famous Google service – Gmail – doesn’t support folders at all. Instead, it has labels.

In Gmail, you can create as many labels as you want, and apply any number of them to an email. Labels are similar to folders: they enable users to categorize and easily search for files – the only thing missing is the hierarchical pattern that folders enable. Which leads me back to Google Drive: I wonder how folders are internally represented within the Google Drive system. Based on the API, it looks like folders are considered a special case of files.

But if Drive can handle folders as simply a special file, why doesn’t Gmail support folders as well? Is it simply that Gmail and Drive are separate codebases, or that Google feels that labels are a better categorizing scheme than folders?

It’s always interesting to think about Google’s architecture and how different services have vastly different builds and APIs.