5 ms·

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 ei

by pekk 11y ago

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.

ryandvm 11y ago
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...
- melling 11y ago
  Khan Academy runs on App Engine: https://cloud.google.com/files/KhanAcademy.pdf https://cloud.google.com/files/KhanAcademy.pdf
- jamra 11y ago
  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.
  - Jabbles 11y ago
    How is that simpler than writing a package that replaces the datastore, then changing your imports?
    - jamra 11y ago
      If that feels simple to you, knock yourself out. 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.
- tdonia 11y ago
  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! https://github.com/likestripes/pacific https://github.com/likestripes/pacific
- tjohns 11y ago
  It's worth noting that there is an open source implementation of AppEngine, for projects that want to self-host: https://github.com/AppScale/appscale https://github.com/AppScale/appscale
  - jfoster 11y ago
    Red Hat also run a hosted one called CapeDwarf.

by pekk 11y ago

ryandvm 11y ago

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...

melling 11y ago
Khan Academy runs on App Engine: https://cloud.google.com/files/KhanAcademy.pdf https://cloud.google.com/files/KhanAcademy.pdf
jamra 11y ago
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.
- Jabbles 11y ago
  How is that simpler than writing a package that replaces the datastore, then changing your imports?
  - jamra 11y ago
    If that feels simple to you, knock yourself out. 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.
tdonia 11y ago
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! https://github.com/likestripes/pacific https://github.com/likestripes/pacific
tjohns 11y ago
It's worth noting that there is an open source implementation of AppEngine, for projects that want to self-host: https://github.com/AppScale/appscale https://github.com/AppScale/appscale
- jfoster 11y ago
  Red Hat also run a hosted one called CapeDwarf.