DynamoDB as a Serverless Service

Chapter Comments
1

Link to chapter - https://serverless-stack.com/chapters/dynamodb-as-a-serverless-service.html

2

Hello, looks like this code is for starting a new project using microservices. Can i still follow this if i want to change my existing app to be in the form of microservices? i.e. i delete serverless.yml in the root and create new serverless.yml files in each service folder? Will this create new S3 bucket, functions and aws resources and delete the existing buckets, resources, functions etc.?
Sorry if this is stupid, i am new to aws, serverless.
Thank you

3

So the key thing here is the name of service in the serverless.yml.

If you change that name and re-deploy, then it’ll create a new set of resources. But it is totally fine if you move the serverless.yml file around in different folders and deploy from there.

1 Like
6

Thank you. So i created serverless.yml files in each service and aws created new resources. i can live with that for now. While creating new serverless.yml files, i deleted everything in the serverless.yml of the root directory except the following:

service: notes-app-2-api

#  Use the serverless-webpack plugin to transpile ES6
plugins:
  - serverless-webpack
  - serverless-offline

custom:
  webpack:
    webpackConfig: ./webpack.config.js
    includeModules: true
  
provider:
  name: aws
  runtime: nodejs8.10
  stage: dev
  region: us-east-1

I am getting the following error when running sls deploy in the root folder:

Webpack Options Validation Error -----------------------
 
  Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
 - configuration.entry should be one of these:
   object { <key>: non-empty string | [non-empty string] } | non-empty string | [non-empty string] | function
   -> The entry point(s) of the compilation.
   Details:
    * configuration.entry should not be empty.
      -> Multiple entry bundles are created. The key is the chunk name. The value can be a string or an array.
    * configuration.entry should be a string.
      -> An entry point without name. The string is resolved to a module which is loaded upon startup.
    * configuration.entry should be an array:
      [non-empty string]
    * configuration.entry should be an instance of function
      -> A Function returning an entry object, an entry string, an entry array or a promise to these things.

Here is my webpack.config file:

const slsw = require("serverless-webpack");
const nodeExternals = require("webpack-node-externals");

module.exports = {
  entry: slsw.lib.entries,
  target: "node",
  // Generate sourcemaps for proper error messages
  devtool: 'source-map',
  // Since 'aws-sdk' is not compatible with webpack,
  // we exclude all node dependencies
  externals: [nodeExternals()],
  mode: slsw.lib.webpack.isLocal ? "development" : "production",
  optimization: {
    // We no not want to minimize our code.
    minimize: false
  },
  performance: {
    // Turn off size warnings for entry points
    hints: false
  },
  // Run babel on all .js files and skip those in node_modules
  module: {
    rules: [
      {
        test: /\.js$/,
        loader: "babel-loader",
        include: __dirname,
        exclude: /node_modules/
      }
    ]
  }
};

Could you tell me how to write the serverless.yml in the root so that the error is resolved?

(and if i remove the webpack info from serverless.yml, i can complete the deploy, but server cannot understand 'import '. and it gives an error in aws cloudwatch: SyntaxError: Unexpected token import)

Thank you

7

I haven’t run across this error before. I’d just compare what you have to the starter project and see what’s different.

8

Hey all! Thanks for the absolutely fantastic tutorial and the community you have created around it. What a brilliant concept! I would absolutely love to contribute to this project.

But admittedly, I can’t consider myself an expert so I would like to ask here if the opportunities I see for improvement are real.

For example, throughout the core tutorial, we were using git for version control with pushes to master firing off fresh deployments. The kind of changes suggested here feel like an opportunity to create a branch in git so that the master branch is untouched while we steer our projects into new territories.

So my questions are: Should I even be creating a new branch in git before making the changes suggested here? Should those instructions be explicit in this chapter? And should I add them here? I assume that if I were to add them here, I would also have to add them to the the other chapters and tie it up at the end with instructions on how to merge the branch back to master at the end.

These questions may seem silly but I have never contributed to an open source project before but I definitely want to contribute to this one but in the right way.

9

Thanks for offering to contribute!

Can you clarify what you mean by creating new branches? Do you mean certain steps in the guide should ask users to create a new branch?

11

Hey Jay. Nevermind. I misunderstood why this section seems so sparse and thought things things like git steps should be added to make it more consistent with the rest of the tutorial. But now I think I understand that the sparseness of this part makes readers go back and review the previous chapters if they are going to try and take on this part. My bad. Keep up the great work! :sunglasses:

1 Like
12

Whats the thinking behind making the userId attribute a HASH SchemaType, and making the noteId a RANGE SchemaType?

13

Well because we want to look up all the notes made by a user. Is there a different schema you had in mind?

14

Nah I was just asking to find out best practise. In your tutorial you never expound on whats the best way to pick HASH and RANGE keys

15

Ah I see. Yeah we’ll add a note to expand on that.