serverless-offline VS awslogs

Using local emulators like sam local, serverless-offline, localstack, etc.

Hi, I'm the creator of serverless-offline (https://github.com/dherault/serverless-offline), a NPM package for local serveless development on AWS.

I'm building a cool product and intend to launch Q1 2023. To gain traction from my target customers, I plan to place a discrete ad at the launch of every serverless-offline instance.

Does it seem like an ok move to you? Or is it something that repels you?

Best,

As the creator of serverless-offline, I am well placed to tell you that this is the time-effective solution. Plus, it costs way less than other solutions at smaller scales. But, again, going Kubernetes or otherwise will be a problem for the future.

https://github.com/dherault/serverless-offline https://github.com/lambci/docker-lambda

What if I didn’t need to push code to AWS every time I wanted to test something? All heroes don’t wear capes. Like a knight in shining armor, Serverless Offline comes barging in to save the day! At least now I can test all my code locally before pushing it to AWS. That’s a relief.

With classic Express servers, you can use a simple node script to get the server up and running to test locally. Serverless wants to be run in the AWS ecosystem making it. Lucky for us, David Hérault has built and continues to maintain serverless-offline allowing us to emulate our functions locally before we deploy.

With the serverless offline plugin you can speed up local dev is by emulating AWS lambda and API Gateway locally when developing your Serverless project.

Those mocks are by definition not real services so there are some behavior differences between the local environment and the cloud provider. For example, AWS API Gateway emulated by serverless-offline doesn't handle VTL locally the same as AWS does.

serverless-offline (https://github.com/dherault/serverless-offline) is a great tool to use for local development of serverless applications.

It's not a complete mirror image of what you get but it's close enough in my experience.

Using the official CLI (aws logs get-log-events) or https://github.com/jorgebastida/awslogs is pretty close to SSH-ing and grepping.

cw is a native executable targeting your OS, and not needed external dependencies such as pip and npm. Compared to awslogs which is famous helpful tool for CloudWatch Logs1, cw is written in golang and faster.

Its a command line tool but some people I know also use awslogs

Not a full solution, but when I was doing this I really got to love the awslogs utility:

https://github.com/jorgebastida/awslogs

It allows you to stream Cloudwatch logs from the command line, so you can grep them, save them to files, etc... (The web based Cloudwatch interface is terrible.)

Another suggestion is to try to modularize the core business logic in your lambda such that you separate the lambda-centric stuff from the rest of it. Obviously, though, if "the rest of it" is hitting other AWS services, you're going to hit the same testing roadblock.

Or you can try mocking, which may or may not provide much value for you. There's a python library for that, (moto), but it's not 100% up to date wrt AWS services/interfaces, last I had checked. Might be worth a try though.

https://github.com/spulec/moto

Cloudwatch Logs is pretty meh visually, but awslogs can give you a pretty good `tail -f`-like experience, and Insights is pretty good. Cloudwatch Metric Filters give you a 'StatsD'-like experience, in that you can log out a certain message or code and then use its appearance as a metric.

Check out https://github.com/jorgebastida/awslogs , you can define a `--start`, and it also has a `--watch`, and can be piped the `grep` or whatever you want. It's a pretty flexible tool.

📖 awslogs - a simple command-line tool for querying groups, streams, and events from Amazon CloudWatch logs.