accessing uri params for websockets api (question)

[fullstackdev-online]

How to access uri query string parameters for websockets API with chalice?

E.g. my gateway uri has extra paramet(s) like wss://my-example-gateway.com/api/?id=some-id&param=value

In nodejs I'd access the id and param values using event.queryStringParameters like in the code below: exports.handler = async (event) => {
id = event.queryStringParameters.id, param = event.queryStringParameters.param, // ... do other stuff };

but in chalice on_ws_connect event argument (type WebsocketEvent) I only see

        self.domain_name = request_context['domainName']
        self.stage = request_context['stage']
        self.connection_id = request_context['connectionId']
        self.body = event_dict.get('body')

[ivandjuricic]

Is something like this you were looking for?

@app.on_ws_connect()
def connect(event):
    params = event.to_dict()["queryStringParameters"]
    print('Params: %s' % params)

[jamesls]

Yeah, it looks like this isn't mapped right now. We currently use a single event class between all the websocket handlers (connect, message, disconnect), but the params such as queryString, headers, etc is only available on the connect handler. The on_ws_message handler has requestContext, body, isBase64Encoded whereas the on_ws_connect has:

headers, multiValueHeaders, queryStringParameters, multiValueQueryStringParameters, requestContext, isBase64Encoded.

While you can use @ivandjuricic's suggestion of event.to_dict() to get access to the underlying event dictionary, I think the long-term fix here should be to have separate event classes for connect, message, and disconnect. That way we can map the additional parameters into the connect handler.

This is technically a breaking change, but given that this is an experimental API I think now's a good time to update this.

Thoughts? /cc @stealthycoin

[fullstackdev-online]

this sounds good and fully makes sense and would be cleaner and more pythonic, though the workaround from @ivandjuricic is also easy to implement. So I'd vote for the enhancement, but it's definitely not a blocker.

[Ankushpandey-ti]

Hey guys any update on this ?

[robmoss2k]

Still no update?