Skip to content
This repository has been archived by the owner on Feb 24, 2024. It is now read-only.

Make Buffalo GAE compatible #213

Open
markbates opened this issue Feb 2, 2017 · 16 comments
Open

Make Buffalo GAE compatible #213

markbates opened this issue Feb 2, 2017 · 16 comments
Labels
breaking change This feature / fix introduces breaking changes enhancement New feature or request help wanted Feel free to contribute!
Milestone

Comments

@markbates
Copy link
Member

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.

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

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

@markbates markbates added this to the 0.8.0 milestone Feb 2, 2017
@bscott bscott added the enhancement New feature or request label Feb 2, 2017
@philipithomas
Copy link
Contributor

philipithomas commented Feb 2, 2017

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.

https://cloud.google.com/appengine/docs/flexible/

@matryer
Copy link

matryer commented Feb 2, 2017

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/

@markbates markbates added the breaking change This feature / fix introduces breaking changes label Feb 4, 2017
@markbates markbates added the help wanted Feel free to contribute! label Feb 14, 2017
@markbates markbates modified the milestones: 0.8.0, 1.0.0 Mar 27, 2017
markbates added a commit that referenced this issue Jun 28, 2017
@niranjan92
Copy link

niranjan92 commented Jul 1, 2017

update GAE now supports go1.8. https://cloud.google.com/appengine/docs/standard/go/release-notes

@niranjan92
Copy link

GAE already has things like memcached, task queues for background jobs etc.

@markbates what components are in plan for GAE compatibility?

@markbates
Copy link
Member Author

Right now the goal is to just get a standard buffalo app to deploy and run on GAE.

markbates added a commit that referenced this issue Jul 10, 2017
markbates added a commit that referenced this issue Jul 16, 2017
markbates added a commit that referenced this issue Jul 27, 2017
markbates added a commit that referenced this issue Jul 30, 2017
@davidhtims
Copy link

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.

@markbates
Copy link
Member Author

markbates commented Dec 6, 2017 via email

@benkraus
Copy link

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.

@markbates
Copy link
Member Author

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

@raylee
Copy link

raylee commented Apr 3, 2018

Just as a data point, go.rice no longer uses syscall. It was removed here: GeertJohan/go.rice@c7060fb

@davidhtims
Copy link

Would Buffalo be compatible with the new Google App Engine standard environment V2 aka Go111 runtime?

@benkraus
Copy link

I saw that too, and had that same thought. Just need to find time to try it. :)

@matryer
Copy link

matryer commented Nov 28, 2018 via email

@markbates
Copy link
Member Author

markbates commented Nov 28, 2018 via email

@sio4
Copy link
Member

sio4 commented Nov 28, 2018

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 don't know and don't consider other parts of the GAE. I just think about pop side for now. :-)

@tombiscan
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
breaking change This feature / fix introduces breaking changes enhancement New feature or request help wanted Feel free to contribute!
Projects
None yet
Development

No branches or pull requests

10 participants