search

maddyblue / goon

Autocaching interface to the app engine datastore for Go
http://godoc.org/github.com/mjibson/goon
ISC License
217 stars 37 forks source link

Make compatible with cloud.google.com/go #74

Open aelsabbahy opened 6 years ago

aelsabbahy commented 6 years ago

Similar to the request at qedus/nds#54

Would it be possible to extend this to work outside of Google App Engine?

xStrom commented 6 years ago

We would have the same problem as discussed in the issue you linked. We depend on google.golang.org/appengine/memcache. To work outside of GAE, we would need a similar memcache package.

Right now there are no plans on creating such a memcache package. However if you know of an existing one, then the porting work shouldn't be too hard.

aelsabbahy commented 6 years ago

Maybe I don't fully understand the problem.

I assumed entity.go is doing most of the heavy lifting, encoding and decoding.

And figured the cache driver and datastore drivers could just be an interface that supports GetMulti, SetMulti, and DeleteMulti, and transactions.

But, I haven't looked at how different the appengine driver is compared to cloud.google.com/go so maybe it's more nuanced.

Wonder if it would be beneficial for encoding/decoding to be it's own reusable package (or just export the serialization functions) as a first step?

delphinus commented 6 years ago

Google will release Cloud Memorystore that is full-managed Redis (announce).

I think it can solve one of the problems.

faisalraja commented 5 years ago

They are also doing the memcache to it's own service.

mycroftcanner commented 4 years ago

This is going to become a pressing issue as appengine/memcache may only have a year and a half left with the 1.1.1 runtime. The 1.1.2 runtime is deprecating all of appengine/*.

xStrom commented 4 years ago

Yes the fate of the Go 1.11 runtime is unclear. I hope they won't deprecate it too soon given how many applications have been written using the appengine APIs.

I have been thinking about the future of goon for the past year or so in light of this. I have some decent ideas how goon could transition into using the cloud datastore and a selection of caching methods instead of appengine/memcache.

I'm still undecided if I want to undertake all of this. It will probably depend on whether any of the applications I work on will need it. For new applications I've been thinking of completely abandoning the Google ecosystem. The reasoning being that Google may just decide to deprecate things at any point like they've been doing with various app engine APIs throughout the years. So might as well just move to a more stable stack (e.g. PostgreSQL) which can't be taken away from me. At the same time I do maintain a couple of reasonably sized applications that can't just be rewritten for SQL. The hope is that Go 1.11 or something like it will exist for years to come. If not, then I'll probably be forced to upgrade goon just to help these applications keep working.

mycroftcanner commented 4 years ago

@xStrom I wish they would open source the whole appengine/* backend and let us continue running stuff if we want to on some compute engine instances or even elsewhere.

AppScale comes to mind but last time I checked it was a bit messy.

apstndb commented 4 years ago

FYI, Google is committed to providing LTS for Go 1.11 runtime. https://cloud.google.com/appengine/docs/standard/long-term-support?hl=en

xStrom commented 2 years ago

Still no update on cloud.google.com/go support and that's unlikely to change in the near future.

However in an interesting twist Google has released google.golang.org/appengine/v2 which works on Go 1.12+.

Those of you who have been stuck on Go 1.11 will now have the possibility to upgrade all the way up to Go 1.16 and beyond. Read more in issue #97.