AWS and JavaScript, these are a few of my favourite things...
Nothing here yet.
No blogs yet.
IDE's come with a whole host of opinions. If your opinions closely match those of an IDE, then go for it! The reality is that it's hard for something so opinionated to work for all scenarios (e.g. languages, projects, etc) all the time. A more minimal approach like vim provides (I'm sorry, I can't suggest Emacs as a minimal approach with a straight face) is more likely to work in more scenarios simply because it gets out of the way of a developer. Combine that with an extensive, mature, plugin system means you can customise it to your heart's content if you choose to.
My current favourite is tape . I've used many of the other popular options (e.g. Jasmine, Mocha, Karma, etc) but find most of them a bit too magical for my personal preference. I find the tap -based runners to be the right amount helpful ( node-tap is OK too, but aimed mainly at NodeJs codebases).
There's no existing solution that I'm aware of, but it's not my field of expertise either. If you specifically wanted to run SpamAssassin, you'll probably have more luck using a container-based solution so that you can actually run the same program, rather than shoehorning the application in to Lambda (even though it might be technically possible to get it running in a Lambda function, depending on the binary's dependencies).
This is what the AWS Cognito service was designed to address. It allows clients (i.e. mobile devices) to exchange login details for short-lived AWS tokens (via the STS service) so that they can access AWS resources directly. You can use this with the IAM Authorizer to force your users to have valid credentials, or you could use it with the Cognito User Pool Authorizer directly. Note that Cognito has the idea of a default user, so that even unauthenticated users (i.e. pre-login) can access certain resources.
Data stores used in serverless/Lambda applications are the same as any other application. The store that you choose will probably depend more on the data and the way you intend to use it than the fact that it's being accessed by Lambda - at the end of the day a client is a client, regardless of if it's serverless or not. Some popular options for Lambda-based applications are: DyanmoDB: Amazon's key/value store (i.e. it's NOT a relational database, so don't treat it like that) which is nice because it is also serverless - you just provision your table, and that's it. S3: Amazon's object store, which can be used like a database in a surprising number of situations. Just remember that it is not a database, and is more of a key/value store (with different performance characteristics to DDB). RDS: Amazon's MySQL/PgSql/MSSQL/etc service. RDS works well when you want/know/love relational databases, especially since it can easily be run with cross-AZ redundancy (meaning an outage won't affect your database or your serverless application). Note that your Lambda functions will need to be VPC-based in order to securely access your RDS instance.
While I haven't made the jump yet, I have been thinking about it. Just in case anyone on this thread hasn't seen it, TJ famously moved from Node to Go . If you don't know who TJ is, it doesn't matter - you've used his code if you've used NodeJs e.g. Express, Koa, Commander, etc.
Ideally you'd start by looking at the tests! If they don't have tests, then write some. Testing code is a great way to understand it. After that I like to start with any small bugs or features, and work my way up from there.
The exact style depends on the convention of the language I'm using (i.e. camelCase for JavaScript, snake_case for Ruby and Python, etc). As far as the intention you can't go wrong with the principals outlined in Clean Code: Use Intention-Revealing Names Avoid Disinformation Use Pronounceable Names Use a Searchable Name To see a summary (not by me), check out this post . Read the original if you can, as it's got many more sound recommendations that I think more developers would benefit from - it's a timeless classic for programming.