jayair

10 ms·

1. 31.▲
   Show HN: How to debug Lambda functions with VS Code(serverless-stack.com)

   12 points by jayair 5y ago|1 comments
2. 32.▲
   by jayair 5y ago

   Wow I really appreciate that! Thank you!
3. 33.▲
   by jayair 6y ago

   Thanks! We had to change the build process of Lambdas to support deploying a mock version of the function. And we need to add a new command that deployed the debug stack. Here's how it works internally — https://docs.serverl
4. 34.▲
   by jayair 6y ago

   We love esbuild and we use it internally for SST https://github.com/serverless-stack/serverless-stack . The work Evan does is seriously impressive.
5. 35.▲
   by jayair 6y ago

   Ah I see what you are saying. Not that this approach is an anti-pattern compared to other serverless setups. But that serverless in general is an anti pattern. I can see where you are coming from. What we are doing with SST does seem very c
6. 36.▲
   by jayair 6y ago

   That's not good! We want to add support to GCP and Azure as well.
7. 37.▲
   by jayair 6y ago

   You could watch our repo — https://github.com/serverless-stack/serverless-stack . Our Twitter account could work also — https://twitter.com/ServerlesStack
8. 38.▲
   by jayair 6y ago

   Thanks! We'd love to cover as many cases as possible. Feel free to open an issue and we'll add it to our roadmap!
9. 39.▲
   by jayair 6y ago

   That's cool to hear! I'd love to see that implementation if possible. LocalStack is a good initiative but in practice it ends up being slow. As a result, we see people using it for writing tests instead of local development.
10. 40.▲
    by jayair 6y ago

    Using these Docker images works well to emulate the Lambda environment for sure. It just falls short when I want to trigger that through, let's say an SNS topic or an authenticated API that my frontend application can connect to.
11. 41.▲
    by jayair 6y ago

    Yeah, the is exactly the way we felt. While SST's internals might be complicated, from a user's perspective you get a "normal" local development experience.
12. 42.▲
    by jayair 6y ago

    We personally do, we've been using Lambdas and serverless for the past 4 years. And we've never had to worry about scaling or downtime. We are a small team, so this has a real impact on us.
13. 43.▲
    by jayair 6y ago

    I'm curious, why do you think this is an anti pattern?
14. 44.▲
    by jayair 6y ago

    There are a couple things that SST does differently. - The Live Lambda Development environment that I talked about in the post. That's really the biggest difference. - And instead of CloudFormation YAML, SST uses CDK. So you can use re
15. 45.▲
    by jayair 6y ago

    Yeah it's a little confusing to describe the difference. But what most of the tools currently do is, locally mock a Lambda function execution. You cannot test anything beyond that. For example, if your Lambda function publishes to a SN
16. 46.▲
    by jayair 6y ago

    Yup, we'll be working on it soon. Interestingly, we get more request for Go than Python!
17. 47.▲
    by jayair 6y ago

    Not sure if you noticed this ( https://news.ycombinator.com/item?id=26323888 ), but it's similar in spirit to the Lambda terminal idea.
18. 48.▲
    by jayair 6y ago

    Not at all. I really like that idea. It makes a ton of sense. I think we'll try and get something like this on the roadmap. Appreciate the feedback!
19. 49.▲
    by jayair 6y ago

    That's a really interesting comparison. The part of SST that I didn't get a chance to touch on in the post is the higher level constructs. These give you more of that framework type feel. Currently we do APIs, queues, cron jobs, a
20. 50.▲
    by jayair 6y ago

    Not at all! SST is built on CDK. So anything you can do in CDK, will also work in SST.
21. 51.▲
    by jayair 6y ago

    Thanks Nick! Appreciate it.
22. 52.▲
    by jayair 6y ago

    Appreciate it! After having struggled with all the confusing serverless related content out there, the docs are a big point of emphasis for the project.
23. 53.▲
    by jayair 6y ago

    Thank you!
24. 54.▲
    by jayair 6y ago

    Thank you, that's awesome to hear!
25. 55.▲
    by jayair 6y ago

    Awesome! While this doesn't quite do the edit in place and I wouldn't recommend running this for prod with live traffic; we use it to run some scripts against prod. You get an environment where you can make changes quickly as oppo
26. 56.▲
    by jayair 6y ago

    Thanks! I hadn't thought of using something like this for mitigating outages. Do you mind elaborating on that a bit more? Currently there isn't a simple way to switch off the debug mode. So if `sst start` deploys the Lambda with t
27. 57.▲
    by jayair 6y ago

    Yeah `sls invoke local` works well for testing individual functions where you are mocking the specific inputs or triggers. But there are a couple of cases where it can become hard to use. For example, if you want to test a Lambda function t
28. 58.▲
    by jayair 6y ago

    Thanks! SST takes a little bit to start up when you run it the first time. But it's pretty fast after that.
29. 59.▲
    by jayair 6y ago

    Yeah it's a good question. The serverless WebSocket API allows us to keep the debug stack entirely serverless. This makes it really cheap (basically free) and it's very reliable because we don't have to manage starting and st
30. 60.▲
    by jayair 6y ago

    The key difference here is that Zappa and the other frameworks emulate the API (or SNS, SQS) service on your local machine. This means that if you want to test an API that requires authentication or if your Lambda function is triggered by s