Some observations about a difficult dev experience

Serverless Framework
1

Hey all, love what you’re doing and the community involved, just wanted to lend an observation that may lead a lot of new devs down a rabbit hole that may be lost on those who haven’t had to solve these problems for awhile. I believe a lot of these can be addressed through the docs.

Normally this wouldn’t be too much of an issue, but searching through the issues/docs/googling actually made finding the solution more confusing.

1. Basic Logging

When I was spinning up some basic functions I threw a few console.log's in and was surprised to not see output. So I went digging for the solution. The first two results from google are:

https://github.com/serverless/serverless/issues/281
https://github.com/serverless/serverless/issues/2416

The first issue basically stops at “This is what environments are for” and then devolves into a discussion on the benefits of learning JAWS. (EDIT: Just learned after some googling that JAWS was the former name of Serverless :wink:) Discussion picks up about a year later about progress on a related issue.

I stumbled across another issue where I noticed the user printing out via sls logs, so I was using that for awhile until I noticed the local flag on invoke which solved all my problems. After reading some issues, perhaps old, in the back of my head I was under the impression that running the functions locally was out of the question.

Solution

Emphasis the ability to debug via sls logs or sls invoke local during the onboarding experience.

2. CLI mentions setting “SLS_DEBUG=*” when functions error

This is related to my past experience before solving locally. I start by googling serverless setting environment variables which turns up general info about setting environment variables, so I attempt to intuit the method to address this concern through the manifest and come up with:

  hello:
    handler: handler.hello
    environment:
      SLS_DEBUG: true

I deploy, and the function is still acting the same as before. Since the syntax between the CLI and googling about the environment variables result in two totally separate syntaxes, I google serverless SLS_DEBUG and get:

https://github.com/serverless/serverless/issues/1690

Which has a suggestion of using export SLS_DEBUG=true which is a third syntax unlike the first two. I now have no idea which of the three to use, nor where:

SLS_DEBUG=* // 1

environment:
  SLS_DEBUG: true // 2

export SLS_DEBUG=true // or 3

And unfortunately none of this is in the docs.

Like I said, I was able to solve my problem by invoking locally, but I wanted to be thorough here because I find these to be pretty basic questions that I’m sure a ton of developers new to the platform will be googling, but the paper trail to getting to the proper solution is really, really hairy.

2 Likes
2

Logging is hard in a server-less environment. The sls logs command is one of the ways Serverless is trying to make it easier for developers. sls local is one of the other ways the framework is making it easier to get feedback quickly, but is relatively recent functionality in the grand scheme of things. Logging is definitely a problem-space with lots of room for improvement.

The SLS_DEBUG environment parameter is for debugging the Serverless Framework, not your functions (which are deployed by Serverless, but not actually running the Serverless code). You use it when you run the serverless (or sls, which is just an alias to serverless) command e.g. sls deploy ..., etc. It doesn’t have any impact in your function, unless you specifically add it.

Nice work sharing your experiences! I think it’s something we all go through, we just try to forget about it… :wink:

3

Thanks for the clarity on the SLS_DEBUG! If there’s a way to increase the transparency/path-to getting at sls local in the docs I think it will go a long way. Googling/searching issues led me to building out-of-date mental models about how to solve these problems, when the solution was buried in version release notes.

1 Like