dynamodb-toolbox
sst
Our great sponsors
dynamodb-toolbox | sst | |
---|---|---|
16 | 179 | |
1,731 | 20,063 | |
- | 2.6% | |
6.9 | 9.8 | |
about 10 hours ago | 1 day ago | |
TypeScript | TypeScript | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dynamodb-toolbox
-
[UPDATED] The DynamoDB-Toolbox v1 beta is here 🙌 All you need to know!
One of them was that it had originally been coded in JavaScript. Although Jeremy rewrote the source code in TypeScript in 2020, it didn't handle type inference, a feature that I eventually came to implement myself in the v0.4.
-
The DynamoDB-Toolbox v1 beta is here 🙌 All you need to know!
If you have in mind features that I missed, or would like to see some of the ones I mentioned prioritised, please comment this article and/or create an issue or open a discussion on the official repo with the v1 label 👍
-
An in-depth comparison of the most popular DynamoDB wrappers
For instance, here is an example of the same UpdateCommand with one of those wrappers, DynamoDB-Toolbox:
- DynamoDB Toolbox
- A simple set of tools for working with Amazon DynamoDB and the DocumentClient
-
Ask HN: Has serverless matured enough for creating user facing APIs?
It's been mature enough for at least four years.
1. Not an issue for me. Connection reuse support in Lambda is quite good
2. NoSQL is a good skill to keep your in bucket anyhow. DynamoDB is a different approach, but much of the same tenets you'll find in other NoSQL databases still apply. Using tools like dynamodb-toolbox [1] help greatly with paradigm shifts into Dynamo.
3. True. Ask yourself how much this matters. How likely is it that you'll need to support another cloud provider for a single product? In 20 years I've seen a platform provider switch exactly once. And DynamoDB can be exported easily.
4. Nope. But there are things to learn about cold starts; how to structure code, where to initialize things, which things should be singletons, etc.
5. Depends on the situations and needs. The right tool for the right job, if you will. I've written GraphQL servers that run on lambda which serve 300k users daily. I've also done the same using Fargate/ECS et al. Much of the decisions revolve around complexity of execution and cost factors (e.g. the cost and complexity of running lambda's to process data often versus a Fargate service). You're getting into Software Architecture now.
6. Again, depends on the situation. You'll need to start thinking about what individual services/components/things are doing, what they need, and how they need to run. Gather that information, and then start cost comparisons using the pricing tools the provider has.
[1] https://github.com/jeremydaly/dynamodb-toolbox
-
Beginners Guide to DynamoDB with Node.js
Note that all these entities will belong to the same DynamoDB table. We define only one partition key and one sort key for this table: both of type string. Key is the values we provide for these keys. As you can imagine, this quickly can become a bit tangled mess. Therefore I recommend to express this 'schema' (e.g. of what types of keys we lay over our base table) in code. Later in this article I will show how this can be accomplished using the DynamoDB Toolbox framework.
-
Dynamodb design with Appsync
I use single table design with app sync through this library: https://github.com/jeremydaly/dynamodb-toolbox
-
Unleashing the power of serverless for solo developers
Serverless Cloud further reduces the cognitive load on developers by automatically applying best practices for APIs, data, storage, CDNs, and more. For example, Jeremy Daly, GM of Serverless Cloud, created the DynamoDB Toolbox to help developers implement the best practices of single table design for Amazon DynamoDB. Serverless Data bakes in those best practices for you and provides a simple interface to manage your data. Similarly, your API endpoint will automatically have a sufficient amount of computational resources by simply using the api interface of our SDK. Serverless Cloud continuously adapts the best configuration for your application, letting you focus on solving business problems, not infrastructure ones.
-
TypeSafe type definitions for the AWS DynamoDB API
I like the idea, especially since I found libraries like https://github.com/jeremydaly/dynamodb-toolbox or https://github.com/sensedeep/dynamodb-onetable not elastic or up to date enough for me and reverted to raw AWS SDK. I look forward to AWS SDK v3 support in your typings!
sst
-
The 2024 Web Hosting Report
We see some great results from using these in conjunction with frameworks such as SST or Serverless, and also some real spaghetti from people who organically proliferate 100’s of functions over time and lose track of how they relate to each other or how to update them safely across time and service. Buyer beware!
-
Hono v4.0.0
> But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs.
Yeah, thankfully SST [0] does the heavy lifting for me. I've tried most of the solutions out there and SST was where I was the happiest. Right now I do 1 functions per endpoint. I structure my code like url paths mostly, 1 stack per final folder, so that the "users" folder maps to "/users/*" and inside I have get/getAll/create/update/delete files that map to GET X/id, GET X, POST X, POST X/id, DELETE/id. It works out well, it's easy to reason about, and deploys (a sizable a backend) in about 10min on GitHub Actions (which I'm going to swap out probably for something faster).
I agree with the secrets/permissions aspect and I like that it's stupid-simple for me to attach secrets/permissions at a low level if I want.
I use NodeJS and startup isn't horrible and once it's up the requests as very quick. For my needs, an the nature of the software I'm writing, lambda makes a ton of sense (mostly never used, but when it's used it's used heavily and needs to scale up high).
[0] https://sst.dev
-
Lambda to S3: Better Reliability in High-Volume Scenarios
We will start by building a project with SST that provisions an API Gateway, a Lambda, and an S3 bucket. Once implemented, we'll look into testing for concurrent write conflicts or exceeding capacity limits.
-
How I saved 90% by switching NATs
I recently deployed a node websocket server using the SST Service construct. Until this point my stack had been functions and buckets. While I had no users 😢, I also had no costs 🤡.
-
Ask HN: What web development stack do you prefer in 2024?
Most my personal and side-business projects have very spiky load or just low load in general. Because of that I love using AWS Lambda as my backend since it scales to 0 and scales to whatever you have your limits set at.
I use SST [0] for my backend with NodeJS (TypeScript) and Vue (Quasar) for my frontend. For my database I use either Postgres or DynamoDB if the fit is right (Single Table Design is really neat). For Postgres I like Neon [1] though their recent pricing changes make it less appealing.
[0] https://sst.dev
[1] https://neon.tech
-
Meta's serverless platform processing trillions of function calls a day (2023)
Yup. Entire core business product for a succeeding startup, though it's a small team of contributors (<10), and a much smaller platform team. Serverless backend started in 2018. Been a blessing in many regards, but it has its warts (often related to how new this architecture is, and of course we've made our own mistakes along the way).
I really like the model of functions decoupled through events. Big fan of that. It's very flexible and iterative. Keep that as your focus and it's great. Be careful of duplicating config, look for ways to compose/reuse (duh, but definitely a lesson learnt) and same with CI, structure your project so it can use something off-the-shelf like serverless-compose. Definitely monorepo/monolith it, I'd be losing my mind with 100-150 repos/"microservices" with a team this size. If starting now I'd maybe look at SST framework[0] because redeploying every change during development gets old fast
I couldn't go back to any other way to be honest, for cloud-heavy backends at least. By far the most productive I've ever been
Definitely has its warts though, it's not all roses.
[0] http://sst.dev
-
Building a sophisticated CodePipeline with AWS CDK in a Monorepo Setup
Along the way, you find an excellent framework, SST. Which is much faster than CDK and provides a better DX1. Here is how you then define your MultiPipelineStack.
-
Create a Next.js Server Component S3 Picture Uploader with SST
SST is a powerful framework that simplifies the development of serverless applications. It offers a straightforward and opinionated approach to defining serverless apps using TypeScript. Built on top of AWS CDK, SST handles the complexity of setting up your serverless infrastructure automatically. SST is an open-source framework and is completely free to use.
- SST – modern full-stack applications on AWS
-
Do you believe AI will replace your job?
SST is an open-source framework designed to facilitate the development and deployment of Serverless stacks on AWS. It operates under the hood by integrating with Amazon CDK. However, its primary benefit is in allowing us to concentrate on creating resources using familiar languages like TypeScript, treating them as Infrastructure as Code (IaC).
What are some alternatives?
typedorm - Strongly typed ORM for DynamoDB - Built with the single-table-design pattern in mind.
LocalStack - 💻 A fully functional local AWS cloud stack. Develop and test your cloud & Serverless apps offline
dynamoose - Dynamoose is a modeling tool for Amazon's DynamoDB
vite - Next generation frontend tooling. It's fast!
dynamodb-onetable - DynamoDB access and management for one table designs with NodeJS
aws-cdk - The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
middy - 🛵 The stylish Node.js middleware engine for AWS Lambda 🛵
esbuild - An extremely fast bundler for the web
nanoid - A tiny (124 bytes), secure, URL-friendly, unique string ID generator for JavaScript
docker-lambda - Docker images and test runners that replicate the live AWS Lambda environment
aws-lambda-power-tuning - AWS Lambda Power Tuning is an open-source tool that can help you visualize and fine-tune the memory/power configuration of Lambda functions. It runs in your own AWS account - powered by AWS Step Functions - and it supports three optimization strategies: cost, speed, and balanced.
serverless-offline - Emulate AWS λ and API Gateway locally when developing your Serverless project