Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Bernd Strehl
    @Strernd
    I think error handling for websockets would be different, because it would make no sense to return 404, this question was related to http handlers.
    Wisen Tanasa
    @ceilfors

    You can achieve that by doing:

    apigateway({
      errorMappings: new Map([
        [".*", () => ({ statusCode: 404 })]
      ])
    });

    See more at the API reference documentation: https://laconiajs.io/docs/api/adapter-api

    Bernd Strehl
    @Strernd
    If I'm working on a PR for a library, like laconia, that possibly could break a lot of lambdas , the process is fine. So I appreciate the rigor of the whole process. Thanks again for building laconia.
    Bernd Strehl
    @Strernd
    it's not yet on npm, is it?
    Wisen Tanasa
    @ceilfors
    @Strernd Actually I've been reading http://hintjens.com/blog:106. There was an opportunity for me to merge your PR faster, something for me to digest
    Wisen Tanasa
    @ceilfors
    @Strernd It's not on npmjs yet if that's what you mean. I was running out of time before work this morning, I'll release it now.
    @Strernd Released to 1.2.0! Do you want to update the documentation?
    Bernd Strehl
    @Strernd
    I'll try to update the documentation.
    Bernd Strehl
    @Strernd

    I'm afraid my PR doesn't work.

    const laconia = require("@laconia/core");
    const { createWebSocketAdapter } = require("@laconia/adapter-api").webSocket;
    
    const webSocketAdapter = createWebSocketAdapter();
    
    const app = async ({ body, context }) => {
      console.log(context, body);
      return "success";
    };
    
    exports.handler = laconia(webSocketAdapter(app));

    sends me an error an the log says

    START RequestId: 61b627b9-067c-4192-8827-24c8f1742c99 Version: $LATEST
    module initialization error: TypeError
        at Object.<anonymous> (/var/task/src/laconia.js:6:26)
        at Module._compile (module.js:652:30)
        at Object.Module._extensions..js (module.js:663:10)
        at Module.load (module.js:565:32)
        at tryModuleLoad (module.js:505:12)
        at Function.Module._load (module.js:497:3)
        at Module.require (module.js:596:17)
        at require (internal/module.js:11:18)
    END RequestId: 61b627b9-067c-4192-8827-24c8f1742c99
    REPORT RequestId: 61b627b9-067c-4192-8827-24c8f1742c99    Duration: 37.97 ms    Billed Duration: 100 ms     Memory Size: 1024 MB    Max Memory Used: 38 MB
    
    module initialization error
    TypeError
    I just tested it by deploying a simple lambda function. Could you take a look at it?
    Wisen Tanasa
    @ceilfors
    Can you try changing the signature to const app = async (body, context) => {
    Without the curly brace
    Bernd Strehl
    @Strernd
    same problem unfortunately
    Wisen Tanasa
    @ceilfors
    I think the other problem is the destructuring in const { createWebSocketAdapter } = require("@laconia/adapter-api").webSocket;. Should have been just createWebSocketAdapter or any name you like ?
    Bernd Strehl
    @Strernd
    I'll try that
    Bernd Strehl
    @Strernd

    Okay, I think I now know what's going wrong.

    const app = async (event, deps) => {
      const body = event.body;
      const context = event.context;
      console.log({body, context, deps});
      return "success";
    };
    
    exports.handler = laconia(webSocketAdapter(app)).register(instances);

    prints the body and context but deps is undefined.
    I think it's because the adapter only passes the event to the app handler, but it has two parameters. That's why I had ...args in my PR. How did you deal with that in the http adapter?

    Bernd Strehl
    @Strernd
    Also with the http adapter, when using serverless-offline something like this appears as a warning
    Serverless: Warning: handler 'laconia-handler' returned a promise and also uses a callback! | This is problematic and might cause issues in your lambda.
    We should look into how the adapter handles this
    Wisen Tanasa
    @ceilfors
    On the warning, originally the code is doing this because of an issue in AWS, but this appears to have been fixed. I guess we can remove the callback now and just use return.
    I will file the issue tomorrow - feel free to file one too, to remove the usage of callbacks
    Does it have any implication to your Lambdas at the moment or is it just a warning?

    Right! So on the adapter problem, you will need to change the adapter to look something like this, this is how it's being handled in the apigateway http adapter:

    const createWebSocketAdapter = () => app => async (event, laconiaContext) => {
      try {
        const output = await app(parseWebSocket(event), laconiaContext);
        return res(output);
      } catch (err) {
        return res(err.message, 500);
      }
    };

    Notice the use of laconiaContext

    Wisen Tanasa
    @ceilfors
    I'm in the middle of trying to add an acceptance test for websocket. What do you think is the best way to make the acceptance tests runnable by everyone? I can create a new account, but that raises the question of security and who would pay for it
    Wisen Tanasa
    @ceilfors
    @Strernd Raised laconiajs/laconia#48
    Bernd Strehl
    @Strernd

    It's just a warning so it's fine for the moment.
    I will open a PR for the context tomorrow

    Is there a way to have the acceptance test executed on CI ?

    Wisen Tanasa
    @ceilfors
    It can run on CI, but I'm quite apprehensive to put my personal AWS credentials there. For example when someone is creating a fork, they can put console.log to environment variables to retrieve the aws secret details. It also brings questions on how I can financially support it
    I can't seem to find out how other open source projects are doing it!
    Wisen Tanasa
    @ceilfors
    @Strernd I'm facing this issue when trying to implement the acceptance test: laconiajs/laconia#49
    Bernd Strehl
    @Strernd
    hm, no clue so far. will look into it
    Bernd Strehl
    @Strernd
    :point_up: June 2, 2019 7:08 PM
    Jep, that's a problem. I can't see an ideal way here
    @ceilfors how did you test #49 ?
    Wisen Tanasa
    @ceilfors
    I tested it with the code attached in the issue. I also realise that when we originally design the websocket adapter, it is there to support $default or any other request coming in. Maybe it's just about being explicit in the documentation about how we intend to use the APIs
    Bernd Strehl
    @Strernd
    Sorry, I meant how did you invoke it?
    Wisen Tanasa
    @ceilfors
    wscat -c wss://...url
    Bernd Strehl
    @Strernd
    I will try to test it on friday on my machine
    Bernd Strehl
    @Strernd
    I just learned that the connect handler should receive a http event
    Wisen Tanasa
    @ceilfors
    @Strernd Just filed a PR here, can you help review? laconiajs/laconia#68
    Bernd Strehl
    @Strernd
    will do tomorrow
    Bernd Strehl
    @Strernd
    @ceilfors do you know if I can use the laconia http adapter for a function that is triggered by a cloudwatch cron?
    Wisen Tanasa
    @ceilfors
    @Strernd That sounds like a new adapter, rather than using the existing http adapter. What kind of data are you trying to adapt? It seems like most of the functions I've written that are triggered by cron has no input at all, or is taking the input from somewhere else
    Bernd Strehl
    @Strernd
    Yes, there's no real input I would say
    Wisen Tanasa
    @ceilfors
    @Strernd Are you actually talking about a Lambda that is re-used for two trigger types?
    Bernd Strehl
    @Strernd
    No, it shouldn't be triggered by HTTP just by cloudwatch
    Wisen Tanasa
    @ceilfors
    @Strernd Raised an issue here: laconiajs/laconia#119. Thanks!
    Bernd Strehl
    @Strernd
    Have you seen load balancer events? That would be nice also, they're a little different from http
    Wisen Tanasa
    @ceilfors
    @Strernd I have not used them! Why would one want to use that instead of API Gateway? Would be great if you can help file that issue too :)
    Bernd Strehl
    @Strernd
    https://serverless.com/blog/framework-release-v145/ It's explained quite good here why one would want to use it
    Hugo Sena Ribeiro
    @hugosenari
    Hi, anyone have some luck with https://localstack.cloud/ ?
    Wisen Tanasa
    @ceilfors
    @hugosenari Good question. We tried it once in our team and we didn't manage to make it work. We actually moved to a pattern where we test more in the cloud, than locally.
    Hugo Sena Ribeiro
    @hugosenari
    I would suggest this for laconiajs/laconia#104 but can make it work for serverless-vanilla example :(
    Wisen Tanasa
    @ceilfors
    @hugosenari Did you mean you "can't"?.. What problem are you facing? Is the problem with serverless framework, laconia, or localstack?