-
-
Notifications
You must be signed in to change notification settings - Fork 577
Make Buffalo GAE compatible #213
Comments
What's the advantage of supporting GAE Go runtime instead of GAE Docker runtime, besides not needing to build separately? We could probably add "basic" support for GAE through the docs using Docker in its current state, perhaps with Travis for building. |
The Flexible environment might be the choice, but I'd love go see if the standard environment could be supported easily before abandoning it. There are some key differences that might sway a user towards either option. The key one for me is that standard environment apps spin up instantly (milliseconds), whereas the flexible environment can take minutes. This means standard environment apps are likely to be cheaper, because they don't need to be constantly running. For a real example, nobody uses Downlist (an app I made) so it's completely free for me. BUT it's always available... try it: https://downlist.io/ |
update GAE now supports go1.8. https://cloud.google.com/appengine/docs/standard/go/release-notes |
GAE already has things like memcached, task queues for background jobs etc. @markbates what components are in plan for GAE compatibility? |
Right now the goal is to just get a standard buffalo app to deploy and run on GAE. |
Is this still a possibility? Any idea of a rough date please? I would be using Google App Engine's Standard Environment not the Flexible. |
This is still scheduled for 1.0, but there is no date associated with it. To make this happen someone who knows GAE well needs to step up and help make it happen.
…-----------
Mark Bates
On Dec 6, 2017, 10:11 AM -0600, David Smith ***@***.***>, wrote:
Is this still a possibility? Any idea of a rough date please? I would be using Google App Engine's Standard Environment not the Flexible.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I've got a bit of Go App Engine (Standard) experience. Would love to help out on this. I'll take a look and see what it'll take. |
@benkraus that would be great! I tried a while back, but gave up as I never use GAE and it needs someone who has some knowledge there to try and get it right. :) This is the repo I was testing with https://github.com/markbates/gapp (it's really, really, really out of date at this point, but it might provide some insight. |
Just as a data point, go.rice no longer uses syscall. It was removed here: GeertJohan/go.rice@c7060fb |
Would Buffalo be compatible with the new Google App Engine standard environment V2 aka Go111 runtime? |
I saw that too, and had that same thought. Just need to find time to try it. :) |
GAE for Go 1.11 just requires a main.go to listen on the port provided in
the `PORT` environment variable. So maybe Buffalo could just support `PORT`
and then there shouldn't be any more work to do :) Of course, access to
other services and capabilities is a different story, but for basic sites I
think it's a winner.
…On Tue, 27 Nov 2018 at 23:54, Ben Kraus ***@***.***> wrote:
I saw that too, and had that same thought. Just need to find time to try
it. :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#213 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGNG-OVUAF8qZ8ySYDLVJ0piIrQ_4s7ks5uzdDCgaJpZM4L1pM8>
.
|
I was able to get a non-db backed up running fairly easy.
I couldn’t quite figure out how to hook up pop to googles postgres though.
I’m not too familiar with GAE though.
First person to write an article on how to deploy a database backed Buffalo app to GAE wins a prize (seriously). :)
…On Nov 28, 2018, 8:30 AM -0500, Mat Ryer ***@***.***>, wrote:
GAE for Go 1.11 just requires a main.go to listen on the port provided in
the `PORT` environment variable. So maybe Buffalo could just support `PORT`
and then there shouldn't be any more work to do :) Of course, access to
other services and capabilities is a different story, but for basic sites I
think it's a winner.
On Tue, 27 Nov 2018 at 23:54, Ben Kraus ***@***.***> wrote:
> I saw that too, and had that same thought. Just need to find time to try
> it. :)
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#213 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAGNG-OVUAF8qZ8ySYDLVJ0piIrQ_4s7ks5uzdDCgaJpZM4L1pM8>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
For the database backed Buffalo app on GAE, It is not directly mentioned about that but I opened issues (proposals) on pop: gobuffalo/pop#281 and gobuffalo/pop#295 for this possibility. (since we live in Cloud World) And @B-Scan mention about his workaround on gobuffalo/pop#281 (comment) . I wrote my basic ideas on the issues and as a first few steps, some PRs are merged into pop. If there are some ideas about it, those will help us a lot! Currently, I am thinking about some approaches including (1) wrapper dialects for existing dialects which has modified connection method but share main functions, (2) abstraction layer for connection and/or caching, (3) or just simply add some connection parameters to determined connection method and backend variations. Any Idea? how about talking them on the proposals on pop? |
I have a draft of this post sitting for some time. Some bits need an update, but I hope it can help anyone who is trying to use the App Engine. How to Deploy GoBuffalo on Google's App Engine That's more or less used to deploy the blog itself, which is running on the App Engine and Buffalo. |
Currently Buffalo is not GAE compatible. I don't use GAE, so I'm definitely looking for support on this. @matryer has offered his assistance as well.
Mat and I spent some time at GoLab in Italy a couple of weeks ago and found that, at least, two things are preventing Buffalo apps from working on GAE.
GAE is currently on Go 1.6 and Buffalo requires 1.7 because of the use of
context.Context
- This should be remedied on it's own in a few weeks when Go 1.8 is released and GAE is updated to support it.https://github.com/GeertJohan/go.rice uses
syscall
which is a no-no on GAE. This would mean the resolvers package would need some reworking, as well as the build command. This could cause breaking changes.The text was updated successfully, but these errors were encountered: