I've been trying out App Engine for Go the last couple weeks for a side project, but it's been a bit of a headache. Having to use their data store was a little annoying to begin with, but I was able to get past that one. Once I started playing with user accounts I was very frustrated to learn that they only support Google Account login functionality... I have been looking at implementing my own but Go doesn't appear to have a common authentication package and the advice often seems to be "roll your own". Any advice for doing this?
That said, this is the only Go hosting service I could find that has a free tier and their development binaries are very well done!
Bit of a shameless plug, but we just announced official support yesterday on Heroku (https://blog.heroku.com/archives/2015/7/7/go_support_now_off...), graduating from our community supported buildpack. We allow you to pick pretty freely which databases and other services you want to you use from our add-ons. We also have a free tier.
Finally if you do give it a try would love to hear any feedback you have.
Personally, I don't put stuff on Heroku because it's costly and inefficient.
Let's say I have a bunch of pet projects and applications I want to run (blog, IRC bouncer, some kind of photo management). They take negligible CPU most of the time and ~128MB RAM each.
If I throw these on Heroku, I have to pay $7/each for 3 separate dynos, for a total of $21. Alternatively I can pay nothing but deal with my stuff being down 25% of the time.
If I throw them on Vultr or DigitalOcean, I pay $5 for a 512MB (768MB on Vultr) box and they all run happily ever after.
Heroku forces me to buy 4x the resources I actually need, which is a huge waste. It'd be nice to share my pool of resources so that if I use 384MB of RAM, I pay for 384MB of RAM or at least only pay for 512MB.
I know it's very unlikely you care about users like me and that's totally fine, I know things like this aren't particularly lucrative. Just thought I'd mention it since you asked about feedback.
Heroku isn't selling blank VMs, though. It's a value-added service -- you don't have to configure servers, build docker images, manage logging, wire up routes, inject service dependencies ... it goes on and on.
PaaSes are expensive if your time is free.
I work for a company which donates enormous engineering resources to an opensource Heroku competitor (Cloud Foundry). As a note, Cloud Foundry lets you specify exactly how much RAM you want to use. You can try it on Pivotal Web Services[0] (hosted by my employers) or BlueMix.
Buildpacks are definitely worth understanding to get the most out of Heroku, but not having official support is a negative. Also, I can't recall what it was but I did check into the community buildpack and it seemed like more effort than it's worth.
That said, I didn't take a very close look so maybe it was easier than I anticipated!
Another shameless plug -- Go has been an officially supported buildpack on Cloud Foundry for more than a year, based on the same buildpack which Heroku have now adopted as official.
You can try it on Pivotal Web Services or BlueMix.
Disclaimer: I was seconded to the Cloud Foundry buildpacks team for ~7 months.
I reckon that "Hey, we just launched a similar product that might deal with some of your problems, have a look!" is a totally legitimate and constructive bit of information to provide.
Your suggested response would provide very little value to the post being responded to. I would elaborate further, but I don't want to derail this thread further. You should just google it.
I think that it is a jerk thing to do if your service is exactly the same as the one in the thread, however in this case the first poster has identified some annoying problems with Google's system, so pointing out your own system which (I assume), doesn't have these problems is constructive advice (In my opinion).
I never said it wasn't useful information to have. Just that it was a classless thing to do. Let your customers speak for you, or blow your own horn in your own announcement thread.
God I hate marketers. Crapping on social norms and basic manners for a quick buck every day of the week.
The guy is not a marketer, hes a product guy at Heroku. He has over 15k karma and a member of HN for ~6 years. This is far from "some spammer decided to hijack a thread about a competitors product".
I really don't get what you're talking about here. It's constructive for anyone that is looking for a free tier of Go hosting, which we know is at least one person.
Yes, I hate over the top marketing as much as anyone, but this isn't that.
I guess it's just me then. The way I see it, this is like the guy who proposes in front of everyone at a wedding. It's not your day, don't come and try and steal the limelight.
Heroku guy should have just pulled the other marketer trick... get a stooge to post a thread asking "Can someone compare GAE and Heroku". This way he could promote his product without looking like a jerk.
In someone else's product announcement thread, STFU about your product. If it's good enough, your customers will mention it. Basic manners really.
As you can see, I've gone way overboard on this. This will be my last post. I'm just pissed because EVERY hn announcement thread is like this. Someone does something and announces it, and you'll see "oh I did it first... and mine is better and cheaper, ignore his".
You ask "I really don't get what you're talking about here."
Well heroku guy knows what I'm talking about... that's why he prefaced his self-promotion with "shameless plug" like all the others that do.
Except saying "shameless plug" doesn't make it any less shameful.
Most people coming to view this are interested in Go hosting support. The fact that Heroku just added this support (with a free tier) is pretty awesome and I don't think I would have found out about it without the "shameless plug." I bet you would have gotten upset at any of the "customers" if they would have posted about Heroku in this thread. I think it's very different than your wedding example.
Raising awareness of relevant products/services in a space with very few products/services is a good thing, I reckon. I don't think it matters that he's from Heroku or what his role there is, as long as the comment is relevant. Heroku is one of the closest competitors to App Engine. This is relevant, as both relate to Go support. It's also not as though he went through every comment thread here mentioning it; it was just one comment.
I think you'd be right if he did it in some kind of obnoxious way, but he didn't.
If you're okay with OAuth providers then https://github.com/markbates/goth gives you the capability to handle more than just Google accounts.
Otherwise, you're right in that there doesn't exist a 'de facto' auth package for Go like Devise in the Rails world. Part of this is because you can't rely on stuff like ActiveRecord, ActionController, etc. to do some of the heavy lifting for you (Go being just a language, not a framework on its own).
FWIW, I'm partway through writing a concise cookie- (and optionally Redis-) backed store that effectively asks you to provide a `User` type that can satisfy `GetID() string` and `IsAdmin() bool` methods. The middleware/lib does most of the work once you call `mypkg.SetUser(yourusertype)` in your login handler.
This obviously doesn't cover features such as password reset emails, user registration, etc because you either have to make a ton of assumptions about your users' design/implementation, keep things limited, or fall into the trap of "provide options for every possible use case".
PS: Ping me via email if you want some guidance. Happy to share some code snippets and/or input as I've been down the roll-my-own path a couple of times already.
What do people mean by "only google account supported", I've been building a web app with app engine and I just ran my own auth using passlib and it's worked fine. I also don't see how they can prevent you from adding oauth from different services onto your app.
The problem I ran into was that with python you could only use certain native libraries provided by google. To use third part unsupported libraries in python you had to do a hack where you submit them with the app but I managed to get it working with a bit of fiddling.
"The daily email quota for billing-enabled apps depends on which billing system your app is using. See Increasing your Daily Mail Quota below to learn how to increase the quota in each case."
"When you enable billing, the email quota remains at 100 messages per day. You must explicitly request a higher mail quota. Go to the Quota Details page of the Admin Console and scroll to the Mail section. There you'll find a link to submit a request for additional email quota. After you submit the request you can monitor its status by visiting the same link again. This will display a page that shows the status of the request: whether the request has been granted, is under review, or has been denied. If the request is granted it may be several minutes before the new quota of 20,000 messages per day takes effect. If the request is denied you cannot make another request to increase mail quota until some time has passed.
If your app needs to send more than 20,000 messages per day, you can sign up for a support package which entitles you to ask for a higher quota."
I've had App Engine projects that were on Product Hunt and Hacker News for a day, and the bill for those days were close to 0. (it did exceed the free tier, but not by much)
You probably wouldn't want to run Reddit on App Engine, but anything with medium traffic or decent monetization should work out just fine.
The only other caveat is that it may depend on what the app does and how you utilize the datastore. If you don't consider cost of the datastore when building an app, it could end up being expensive like you mentioned.
If you're willing to spend $5/mo then DigitalOcean is a safe bet with excellent reliability. If you're a new customer then google for a Coupon before you sign up (saves you $20).
Don't try to go even cheaper, that way lies madness.
You cant compare AppEngine with DO or Heroku with AWS.
Yes, AppEngine is costlier than DO 5-10X is comparing cost of computation power. You pay the price for not having to deal with DevOps, scalability and some cool API/services.
I've been using Go on App Engine for the past 6 months for a weekend project. My goal is to build a little search engine for Swift language/iOS resources. At the moment, I don't crawl any sites, just search titles and tags. I've been happy with the performance. Seems snappy?
Yes, I'm an engineer. :-(. I was going for a simple Google results look. I had something that I thought was nicer but Google wanted mobile ready pages so I made it sparse.
No worries, I was just wondering if something was wrong on my end. There's a lot of simple things you could do to make it look better, you can start by pushing the whole site up. Right now most of the valuable content happens below the fold of the site. A lot of the stuff on top either doesn't need to be there or doesn't need to be the size that it is, so just prioritizing the screen space for results would go a long way. Then you can do simple things like adding dividers between results.
Hard to say. My current plan is to simply cobble something together. I do have a simple Go Web Server that I used when I started my other Go web server on Digital Ocean:
Whether to use Go on App Engine or not is a much less important question than whether to use App Engine or not. Java is also a good choice on App Engine. But either way, using App Engine dramatically affects almost any decision you'll make about how to build, and it ties your fortune to the sometimes-capricious product decisions made for App Engine.
This cannot be stated strongly enough. App Engine is a powerful platform, but the lock-in is very real.
It's not that Google prevents you from getting your data, but as you develop you start to lean on more and more App Engine specific services (e.g. Datastore, identity, images, task queues, etc.) just because they're so convenient to integrate with. You also have to engage in a lot of funny little hacks to deal with App Engine idiosyncrasies.
The next thing you know, you've got 50,000 lines of code and the thought of porting it all to another platform with an identical topology is hardly any more palatable than the prospect of rewriting it all from scratch (since you've invariably accumulated warts you'd like to refactor anyway).
App Engine is great for MVPs and toy projects. And it can be great for large scale projects, but you better be sure you'll never want to run it anywhere else...
One of the techniques to mitigate that problem specifically in Go is to create interfaces for everything. For example, instead of calling the datastore directly, create an interface with only the methods you need. Then, if you need to swap out your data store, you do so from the implementation of the interface, not having to change the code your business logic runs in.
I believe this is way simpler. Using interfaces will coral your datastore code into one location. Then, you only need to change that code in a very modular way. Heck, give the job to a friend and go for a walk. You can review the changes he made later without worrying that he crossed your routes up. Heck, you can even run your tests (same tests as before since you are using an interface) against your new datastore.
Basically just a proof of concept at this point, but I've been hacking on something that would help mitigate these concerns for people who like App Engine's Golang abstractions, but not the lock-in. Contribs / thoughts welcome!
I have been really enjoying Go App Engine support for some time now. It's pretty convenient to write web apps in Go, although to be fair all my projects have been super simple. I don't really have any experience making anything beyond a simple forum.
Digital Ocean is (I believe) a virtual machine hosting service. You get a VM with some OS and an ip address.
Google App Engine is a very tightly controlled, and very inflexible, system for deploying applications which use google's App Engine services, Datastore, task-queues and an array of other useful things.
App Engine provides a very restricted development environment, you can choose from three programming languages, Python, Java and Go. For each of these they provide a custom modified runtime/compiler for running/building your application. The trade-off for this is that App Engine is able to automatically scale the number of instances of your application running to meet user demand (if you are able to pay for it). The restricted environment is somewhat idiosyncratic and is designed for scalability of stateless servers with a large, also idiosyncratic, datastore with memcached caching for speed. Good for a wide range of web-service development preferably with lots of independent requests which touch separate pieces of data.
It may not sound like it from the description, but I really like App Engine. But, it is important to know what it is for, and what it is not for.
You left out one of the huge benefits of app engine. Google are responsible for keeping the stack secure. You deploy your code, and can trust that it's running on a secure kernel, web server, etc.
I haven't used App Engine+Go yet, but did a bunch of work with AE+Python a while back.
The biggest difference is that you don't have to do any server management. You toss your app to Google, and they handle all of the deployment, distribution to multiple machines, load balancing, etc. I'm assuming that's the case for AE+Go as well.
PSA: Google is notorious for blatantly lying about App Engine availability. Today’s yellow alerts and red exes, on the uptime/status page, somehow always become yesterday's green checks.
(This was a first-hand source of frustration for the team I was working with a few years ago.)
There have been incidents that Google didn't acknowledge at all. There was one day where all sites using custom domains were redirected to Google.com for several hours, including their own Chrome Web Store. (which, I presume, runs on App Engine)
It eventually resolved after a few hours, but both during & after the incident, there wasn't any public communication from Google.
Well I can certainly hope they upped the honesty factor. (My experience is from 2010 & 2011. If the page you linked to is indeed the new version of the one I recall — is there no standalone App Engine status page? — then it’s certainly be massively redesigned.)
AWS is notorious about displaying outages as green (plus an "informational message"). I think we can assume that everyone games the numbers as hard as they think they can get away with.
That said, this is the only Go hosting service I could find that has a free tier and their development binaries are very well done!