SAM version?

[boxabirds]

Hi I love Serverless but corporate clients are generally hesitant to use third party elements in the core flow. SAM has come along a bit in recent times -- have you thought of doing a SAM version?

[jayair]

Hmm yeah thats a good point on the corporate clients part. We didn't have plans but I'll have a look at SAM and see how far along they are.

Contributions are welcome though!

[boxabirds]

I’ll definitely contribute if I get far enough in this direction. This stack has been unbelievably good. When I start earning myself I’ll definitely sponsor it.

[m0un10]

@jayair how would you prefer to see contributions in regards to SAM?

1. As an addition to every part when it references serverless, it would have underneath that how to do with sam?
2. A copy of the whole document structure with serverless parts replaced by sam?
3. Use variables in the static site, so the choice of serverless and sam can be changed at site build-time (e.g. auto-framework=sam)
4. Something else?

[boxabirds]

Personally I think the juxtaposition of individual steps would be really good. That way people can really see the benefit of serverless.com as well.

[jayair]

@craigbarrau I think it's really hard to do each of the parts side-by-side and keeping them updated over time.

It might be easier to create a separate section that shows how to build out the same backend but with SAM. And then allowing the frontend section to use either backend.

We might even change the design of the homepage to indicate that you can use either backend.

[m0un10]

Thanks @jayair. I recently went through the tutorials from the beginning and used sam instead. I think you are right that a separate section would probably be the easiest way to express the alternative option at least in the short-term.

I've just pushed my sam version of the API here and I'd be keen for feedback. I've also got some detailed notes on the gotchas and limitations compared to serverless as well as some of the benefits I found for sam over the serverless framework.

If you are seriously interested in bringing SAM support into the guide, I'd be more than happy to help as a collaborator or the primary author.

As an aside, and in reply to @boxabirds comment, the tools were a lot less different in terms of functionality and syntax than I thought they would be. One of the main things that I noticed was that sam doesn't try to own the build space as much as serverless. That wasn't a big deal as I learned that the magic of the serverless-bundle plugin seems to be easy to do with plain ol' webpack + npm.

[boxabirds]

@craigbarrau amazing! This is really exciting work, thank you! Honestly as a newbie in this space, the tutorial was extremely well done and with sam it should become a mainstream seminal text.

Really, thank you, on behalf of all the budding AWS developers now and in the future.

[jayair]

@m0un10 Awesome! Thank you for this.

I've also got some detailed notes on the gotchas and limitations

Do you mind sharing these? Either in your repo README or here?

I'd like to go through your repo and try setting it up myself. And then put together a rough list of the steps and figure out how we can work together to get this done. Thanks again for offering to help.

[m0un10]

I've got a gist here with my original notes. It also has some details around what is different for the first few chapters when SAM is used instead of the Serverless framework. I didn't have a chance to describe the differences in as much detail for the later chapters but it becomes pretty self explanatory and the full set of changes are available in the sam fork.

[jayair]

Perfect. I'll have a look. Thanks.

[jayair]

I didn't realize SAM requires Docker installed and running. Is there a way around this?

[m0un10]

This is how SAM simulates the function calls locally when you run a test (e.g. sam local invoke or sam local start-api). It pulls down images to support whatever runtime is defined in the template.yaml. If you were simply wanting to build/deploy I don't think Docker would be needed. The deploy step is essentially a convenient wrapper around aws cloudformation deploy.

[boxabirds]

If you need to build native binaries I think you still need Docker though, right?