Clojurians Log v2

======================== @mobileink : so now, the thing that @nickbauman and I want (which I think you also want is): when deplying to remote cloud gae server, can we do this faster than 10-20 seconds? and the answer, we believe is "yes" -- because gae jvm allows you to run clojure's eval so the idea is: new way of deploying to gae cloud 1) take all your clj files 2) store the clj files in datastore/storage 3) when the server needs to run a handler, it (1) pulls clj files from datastore/storage -- and evals it on the fly this of course, is too ezpensive for production, but fine for "testing on remote cloud gae"

ok, i'm trying to digest the lambda-startup thing. looks like it runs a jetty that is not the official gae jetty.

in my understanding, it's about doing two things:

boot-gae never does that.

boot-gae never does what ?

only the official stuff.

i.e. to test you run the googly devserver.

with lambdastartup, you also run the "googly devserver" with all it's stubs for datastore/storage/....

regarding deployment, i'm not sure i see the problem.

the "googly devsever" provides some code for simulating APIs, but afaik is not in itself a jetty server

deployment: some ppl, myself included, don't like wiating 20 seconds for the WAR to package then naother 10 seconds for google to restart the jvm -- just to test it on the actual gae cloud server

the devserver, like the prod server, is a jetty derivative.

hmm, at this point, I should probably study boot / migae before making more comments

as I feel like I'm misunderstanding fundamentals

i think we might be tslking past each other. to me, you deploy rarely. get it right in dev/test, then deploy. so its not a productivity issue, to me.

a while back, I had this crazy bug where things worked fine in local/dev but always died on cloud/gae ... and after that, I wanted "faster deploy" ever since, -- since deploy time was my ottleneck

all the other gae solutions i've seen (not sayig i've seen them all) aot everything and (sometimes) use sth other the google-supplied devserver for local dev testing. boot-gae was partially inspired by the desire to always use the google devserver, and only aot compile what is necessary, not everything.

i'm not understanding why deploy time is a problem.

you should not deploy sth unless you already know it's good, no?

Yeah my concern had always been in developer flow locally. Once in a blue moon I have a test that passes locally but the code fails in the cloud.

if you're deploying to test, then you're doing it wrong. boot-gae helps you get it right before you deoloy (in theory).

I don't buy that argument; if I could have my cider repl connected to remote-cloud-gae insta4d of local-dev, I would.

@nickbauman yes, this can happen. the local test env is unfortunately not quite an exact replica of the prod wnv.

@qqq can you elaborate? when i dev a gae thing cider is largely irrelevant. you're scaring me again; i intuit that i'm about to find out that i've been doing it all wrong. which would not be a new thing.

@mobileink : at this point, it's clear both you and nickbauman know much more about GAE than I do; so I don't think you're doing anything wrong when developing, I like being connected to a live repl ;; right now, I can only be connected to my local-dev ;; in a hypothetical world where I could run nrepl on gae (we can't), I'd love to have my cider directly talking to the nrepl on gae

@qqq ok, but you're a great test case ;). one point that may not be clear: there is no genuine REPL in gae dev. But there is a quasi-REPL, at least in boot-gae: edit code, save changes, refresh page, see changes. that's not so bad, is it?

of course, tmyou might be able to enbed an nrepl thingie in your app, but that's a whole 'nother story.

there is genuine repl for local-dev-gae -- that's what the lambda startup page achieves, but I do agree there's no repl for remote-cloud-gae

@qqq you said "a while back, I had this crazy bug where things worked fine in local/dev but always died on cloud/gae". it would be useful to have more info. in particular, what exactly does "local/dev" mean? a third party server, or the gae devserver?

local/dev = running on localhost, the google dev app server thingy remote/cloud = running on google cloud

in particular, my bug was: requesting /ah/_start = causes the jvm to throw an exception and die so on localhost, everything worked fine on google cloud -- google checks if the jvm is up yet -- and kills the jvm in the processes

took me an afternoon to figure out wtf was going on

i took a look at http://lambda-startup.com/developing-clojure-on-app-engine/ and as I suspected, to get repl-like behavior it is running Jetty, not Google’s devserver. That means it has to mock stuff that the devserver already does. I definitely wanted a solution that uses the devserver. the techniques boot-gae uses eliminate the need to restart to eval changed code, but still use the devserver.

FYI a blog post on boot-gae: http://blog.mobileink.com/2017/01/building-clojure-apps-on-google-app.html

@qqq, @nickbauman it may be possible to embed an nrepl server in a gae app using https://github.com/cemerick/drawbridge/blob/master/README.md. haven't tried it myself.

It's funny but the Python SDK has allowed interaction with your cloud service through the remote API for almost a decade.

link?

https://cloud.google.com/appengine/docs/python/tools/remoteapi

I don't think this exists on the Java side though.

For Python projects, I use (and maintain) this library: https://github.com/agostodev/substrate You can connect to your project with it using a simple command in the root of your project, like so: ./manage.py rshell Note, however, the code that executes is your local codebase, not the remote, so it’s kinda dangerous.

https://cloud.google.com/appengine/docs/java/tools/remoteapi. but that's not a repl.

@mobileink : drawbridge is very nice, but I thikn gae assumes it can kill / restart jvms at will

which would mean all def/local bindings would vanish

you can run a resident instance, see https://cloud.google.com/appengine/docs/java/how-instances-are-managed

@kurtc