https://blog.lonfo.fr/tags/dynamodb/Recent content in DynamoDB on Lonfo BlogHugoen-USTue, 20 Oct 2026 09:00:00 +0200https://blog.lonfo.fr/posts/daily-actions-list-dynamodb-query-api-gateway-lambda/Tue, 20 Oct 2026 09:00:00 +0200https://blog.lonfo.fr/posts/daily-actions-list-dynamodb-query-api-gateway-lambda/<h1 id="daily-actions-read-your-data-back-with-a-dynamodb-query-behind-get-actions">Daily Actions: Read your data back with a DynamoDB Query behind GET /actions</h1> <p>In the previous article, our users learned to <strong>write</strong>: a signed-in user sends an action to <code>POST /actions</code>, a Lambda stores it in DynamoDB, and anonymous requests are rejected. But if you add a task and refresh the <code>/todo</code> page, the list stays empty. Nothing reads the data back.</p> <p>In this article we add the missing half: a <code>GET /actions</code> endpoint that returns <strong>only the actions of the signed-in user</strong>, using a DynamoDB <code>Query</code>.</p>https://blog.lonfo.fr/posts/daily-actions-secure-api-gateway-lambda-dynamodb-with-cognito/Tue, 13 Oct 2026 09:00:00 +0200https://blog.lonfo.fr/posts/daily-actions-secure-api-gateway-lambda-dynamodb-with-cognito/<h1 id="daily-actions-save-data-in-dynamodb-through-an-api-gateway-and-lambda-secured-by-cognito">Daily Actions: Save data in DynamoDB through an API Gateway and Lambda secured by Cognito</h1> <p>In the previous article, our static Next.js application learned to authenticate users with Amazon Cognito. But a login page protects nothing by itself: as long as our backend accepts anonymous requests, anyone can write into our database.</p> <p>In this article we connect the pieces. The signed-in user will send a new action to an API Gateway endpoint, a Lambda function will insert it into DynamoDB, and <strong>only requests carrying a valid Cognito token will get through</strong>.</p>https://blog.lonfo.fr/posts/how-to-design-a-high-performance-dynamodb-table/Mon, 14 Sep 2026 12:25:40 +0100https://blog.lonfo.fr/posts/how-to-design-a-high-performance-dynamodb-table/<h1 id="how-to-design-a-high-performance-dynamodb-table">How to Design a High-Performance DynamoDB Table?</h1> <h2 id="introduction">Introduction</h2> <p>If you are coming into the world of DynamoDB with a relational background (PostgreSQL, MySQL, Oracle), forget everything you know. The first mistake 90% of developers make is designing a NoSQL database like a SQL database: creating tables per entity, excessively normalizing, and hoping to run clean <code>JOIN</code> later.</p> <p>Result? It is a guaranteed crash in production: collapsing performance, exploding AWS costs, and impossible queries.</p>https://blog.lonfo.fr/posts/give-memory-to-your-api-build-a-complete-crud-with-dynamodb-and-cdk/Fri, 14 Nov 2025 12:25:40 +0100https://blog.lonfo.fr/posts/give-memory-to-your-api-build-a-complete-crud-with-dynamodb-and-cdk/<h1 id="give-memory-to-your-api-build-a-complete-crud-with-dynamodb-and-cdk">Give memory to your API: Build a complete CRUD with DynamoDB and CDK</h1> <p>In the previous articles, we gradually introduced you to serverless, starting with the creation and deployment of a Lambda function in the first article, followed by the addition of an API Gateway to trigger the Lambda in the second article. In both cases, the returned data consisted of simple mock responses. You have therefore acquired a solid foundation to move on to the next level: data persistence. As stated in the title, we will use DynamoDB and remain within the same approach: the discovery of AWS CDK.</p>