-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Local Development Proxy Server #164
Conversation
require 'test_helper' | ||
|
||
class ProxyServerTest < LambySpec | ||
include Rack::Test::Methods |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fun time learning how to use this higher up Rack testing.
@@ -0,0 +1,7 @@ | |||
namespace :lamby do | |||
task :proxy_server => [:environment] do | |||
require 'webrick' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, there is a peer (not runtime) dep on WEBrick here. If this feature were more public, I would document that somewhere. Will likely add that docs to the live development project.
lib/lamby/proxy_server.rb
Outdated
end | ||
|
||
def lambda_to_rack(response) | ||
[ 200, {"Content-Type" => "application/json"}, response.to_json ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reminder, the JSON payload here is the full Lambda response which could have any status code, body, etc. The 200 here is the proxy response. No need to convey the local dev Lambda response higher up.
module Lamby | ||
class ProxyServer | ||
|
||
METHOD_NOT_ALLOWED = <<-HEREDOC.strip |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did not use ActiveSupport here intentionally. We never coupled to that since this is a Rack project.
def event_and_context(env) | ||
data = env['rack.input'].dup.read | ||
json = JSON.parse(data) | ||
[ json['event'], Lamby::ProxyContext.new(json['context']) ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This contract will be documented in the Live Development project.
In support of the following work where we now need a fast feedback loop for the final WebSocket integration work.
The idea is pretty simple, within an app like the
websocket-demo
one, we would start a development proxy server within the context of the Rails Application usingrake labmy:proxy_server
. This will start up a WEBrick web server that accepts a simple endpoint to POST Lambda event & context objects as a single JSON structure like{"event": {}, "context": {}}
. All the proxy server does is send this right down toLamby.cmd
where everything the app needs to do from web requests, jobs, websockets, etc... JUST WORKS™. The result of that call is a standard Lambda response like{statusCode: ..., headers: ..., body: ...}
or whatever. The idea is the proxy server need not care. We simply take the Lamby.cmd response and stuff it into the JSON body of the Rack response. Tooling (not specified here) would take that HTTP response body and send it directly to the "Lambda Proxy" as if the Lambda itself did all the work. The fun looks something like this. The important part to call out is that all the pink lines are local Rails (in our case) talking to AWS Resources. So cool!Tailscale Lambda Extension for Containers: