在React Native/React JS应用中直接使用AWS SDK操作DynamoDB的可行性及弊端咨询

Great question! Let’s break this down into feasibility and the critical downsides you need to consider:

Is this technically possible? #

Absolutely. You can directly use the AWS SDK for JavaScript in your React or React Native app to run PutItem (or any other DynamoDB operation) against your table—assuming you:

1. Configure valid AWS credentials for the client (e.g., via Amazon Cognito Identity Pool to get temporary, scoped credentials)
2. Attach an IAM policy to the client's identity that explicitly allows dynamodb:PutItem on your target table.

Here’s a quick code snippet to illustrate:

import { DynamoDBClient, PutItemCommand } from "@aws-sdk/client-dynamodb";

// Initialize DynamoDB client with credentials (typically from Cognito)
const ddbClient = new DynamoDBClient({
  region: "us-east-1",
  credentials: {
    accessKeyId: "<temp-access-key>",
    secretAccessKey: "<temp-secret-key>",
    sessionToken: "<temp-session-token>"
  }
});

// Function to write an item to DynamoDB
const saveItemToDDB = async () => {
  const putCommand = new PutItemCommand({
    TableName: "YourTargetTable",
    Item: {
      user_id: { S: "user_12345" },
      username: { S: "jane_doe" }
    }
  });

  try {
    const response = await ddbClient.send(putCommand);
    console.log("Item saved successfully:", response);
  } catch (error) {
    console.error("Failed to save item:", error);
  }
};

What are the major downsides? #

While technically feasible, this approach is strongly discouraged for production applications due to these critical issues:

• Catastrophic security risks
  Even with temporary Cognito credentials, malicious users can extract them via app decompilation, network sniffing, or browser dev tools. Once obtained, they can use those credentials to perform any DynamoDB action allowed by the IAM policy—like deleting your entire table, exfiltrating all user data, or modifying entries they shouldn’t have access to. Overly permissive IAM policies here are a ticking time bomb.

• No centralized business logic enforcement
  All data validation, access control (e.g., "users can only edit their own items"), and business rules have to live in the client code. This is trivial to bypass: a bad actor can modify the client code or manipulate API requests to write invalid data, impersonate other users, or skip critical checks like payment verification.

• Poor scalability and maintainability
  If you later need to add new logic (e.g., trigger a notification when an item is saved, sync data to another database, or update a related table), you’ll have to push updates to every client device. With an API Gateway + Lambda layer, you can modify backend logic once and have all clients pick up the changes immediately.

• Higher latency and cost vulnerability
  Client-side requests go directly from the user’s device to DynamoDB, which can mean higher latency for users far from your AWS region. Worse, malicious users can flood your table with requests to exhaust your read/write capacity units, driving up your AWS costs exponentially (a form of financial DDoS).

• Limited debugging and observability
  Client-side DynamoDB requests are scattered across thousands of devices, making it nearly impossible to track errors, monitor usage patterns, or debug issues efficiently. With a backend layer, you can centralize logs, set up alerts, and analyze traffic in one place.

Final Recommendation #

Stick with the API Gateway + Lambda pattern for production. It acts as a secure, controllable middle layer that keeps your business logic and DynamoDB access locked down, while giving you the flexibility to scale and maintain your app easily.

内容的提问来源于stack exchange，提问作者Yusuf