DEV Community: Yosbel Marín

Could Your Serverless Database Be Costing You Too Much? Meet Coldbase.

Yosbel Marín — Fri, 06 Feb 2026 14:26:00 +0000

Building serverless apps is great, right? Fast to build, scales easily. But sometimes, those database bills can be a surprise. Popular serverless databases often come with costs that grow quickly.

What if there was a different way? A simpler database designed for serverless that helps you manage costs better?

That's where Coldbase comes in.

Coldbase is a small, serverless-focused database. It uses affordable cloud storage, like AWS S3 or Azure Blob, to keep your data. It's a different approach to storing data in serverless environments. It is currently in Beta, and we welcome your feedback as we continue to refine it.

Why Database Costs Can Add Up

Serverless databases are great for many things, but their pricing can sometimes be high. They often charge based on how many reads and writes you do. As your app gets more users, these costs can increase quickly.

Coldbase's Simple Idea: Cloud Storage as Your Database

Coldbase takes a different path. It uses standard cloud storage (like S3 or Azure Blob) as its foundation. These services are known for being very affordable, especially for storing lots of data and handling many operations.

By building on this low-cost storage, Coldbase aims to give you significant savings on your database bill. We've seen it be much cheaper than some traditional options. For a more detailed look at the cost difference, you can check our comparison here.

Coldbase Features: Simple Tools for Serverless

Coldbase offers features to help you build serverless applications more efficiently:

Works with Serverless: Designed for serverless functions (like AWS Lambda). It doesn't hold data in memory between calls, which fits the serverless way.
Affordable Storage: Uses cloud storage you already know (AWS S3, Azure Blob, or local files) to keep costs low.
Vector Search: If you're working with AI, it can store and search vector embeddings. This can be useful for semantic search or RAG applications.
Automated Housekeeping: It can automatically tidy up your data files (compaction and vacuuming) in the background, without you needing to manage it.
Easy Data Access: Find your data with simple queries, filtering, and pagination.
Batch Operations & TTL: Write many items at once or set data to expire automatically.
HTTP API Option: You can quickly add a REST API using Hono, complete with basic security and documentation.

Quick Start: Try Coldbase with AWS S3

Want to see Coldbase in action with a cloud storage backend? Here’s a simple example using AWS S3.

import { Db, S3Driver } from 'coldbase'
import { S3Client } from '@aws-sdk/client-s3'

interface User {
  id: string
  name: string
  email: string
  role: string
}

// Configure your S3 client
const s3Client = new S3Client({ region: 'us-east-1' })

// Instantiate S3Driver with your bucket name and S3 client
const db = new Db(new S3Driver('my-coldbase-bucket', s3Client))
const users = db.collection<User>('users')

// Add a new user
await users.put({ id: 'u1', name: 'Alice', email: 'alice@example.com', role: 'admin' })

// Find a user
const user = await users.get('u1')
console.log('Found user:', user)

// Get all admins
const admins = await users.find({ where: { role: 'admin' } })
console.log('Admins:', admins)

// Remove a user
await users.delete('u1')
console.log('User u1 deleted.')

Coldbase is a practical way to manage data in serverless applications, with a focus on cost-efficiency. If you're looking for an alternative to high database bills, consider giving Coldbase a try.

Repo here

Escape JS try-catch hell with Untry

Yosbel Marín — Tue, 15 Oct 2024 17:21:32 +0000

Error handling is a crucial aspect of software development, ensuring applications remain stable and user-friendly. However, managing errors in JavaScript can be cumbersome and time-consuming. That's where Untry comes in – a lightweight library that simplifies error handling.

JavaScript error handling.

JavaScript error handling relies on try-catch blocks, which can become unwieldy and difficult to manage, especially when dealing with nested asynchronous calls. This approach can lead to:

Unhandled errors slipping through the cracks
Difficulty in cleaning up resources after errors occur
Code cluttered with error handling logic

Overly complex and deeply nested try-catch blocks creates a maintenance nightmare. By attemptin to handle errors using multiple layers of try-catch statements leads to code obfuscation, error masking, and swallowed exceptions. Asynchronous code and callbacks exacerbate the problem.

Let´s see an example of how complex can become try-catch error handling in JavaScript. Taking an eCommerce API endpoint that fetches product details:

app.get('/product/:id', async (req, res) => {
   try {
      const product = await fetchProduct(req.params.id)
      const reviews = await fetchReviews(req.params.id)
      res.json({ product, reviews })
   } catch (error) {
      res.status(500).send('Something went wrong!')
   }
});

If either fetchProduct or fetchReviews fails it will return the same generic response.

Let's refactor in a way that we can handle errors individually for each async call, and decide what to do in each case:

app.get('/product/:id', async (req, res) => {
   let product
   let reviews
   let productError
   let reviewsError

   // product
   try {
      product = await fetchProduct(req.params.id)
   } catch (error) {
      productError = error
   }

   if (productError) {
      res.status(500).json({ error: productError })
      return
   }

   // reviews
   try {
      reviews = await fetchReviews(req.params.id)
   } catch (error) {
      reviewsError = error
   }

   if (reviewsError) {
      res.status(500).json({ error: reviewsError })
      return
   }

   // final response
   res.json({ product, reviews })
})

Now the code handles each case separately, although it seems less readable and therefore less maintainable.

Let's make it possible to handle each case separately without sacrificing much readability by using Untry:

app.get('/product/:id', async (req, res) => {
   let [product, productError] = await untry(() => fetchProduct(req.params.id))
   if (productError) {
      res.status(500).json({ error: productError })
      return
   }

   let [reviews, reviewsError] = await untry(() => fetchReviews(req.params.id))
   if (reviewsError) {
      res.status(500).json({ error: reviewsError })
      return
   }

   res.json({ product, reviews })
})

What is Untry?

Untry is a lightweight JavaScript library inspired by Go's error handling philosophy. This approach eliminates the try-catch flow. Allows the explicit error management using error as value, not as exception.

How Untry Works

Untry executes a function, catches any error inside, and returns an array containing the resulting value and any thrown error. It is a simple solution for managing errors, making your code more robust, readable, and maintainable.

import untry from 'untry';

let [value, error] = untry(() => {
  // code that might throw an error
});

Key Benefits

Simplified error handling
Explicit error management
Easy cleanup on failure
Customizable error handling
Streamline Your Development

With Untry, you can:

Write more robust code
Reduce error handling boilerplate
Escape try-catch hell

NPM Package: https://www.npmjs.com/package/untry

The library that allows to use JavaScript as the query language for your API

Yosbel Marín — Mon, 27 Jan 2020 19:43:52 +0000

Working in the field of software engineering for a decade, I experienced the rise and fall of SOAP, adopted REST and assessed GraphQL. The web race is for speed, every new alternative technology adopted today is justified only if it makes our web applications faster, more efficient, maintainable and more scalable.

GraphQL became a good candidate to avoid the problems I had when implementing APIs using REST. Some of them are, over-fetching, under-fetching and back-end negotiations on status codes and HTTP verbs.

In the first attempts to use GraphQL, I began to worry about performance issues around N + 1 queries, so, instead of continuing to spend more time reading an extensive and well-written specification and recipes for problems that I have not yet encountered. I decided to create my own library to query APIs regarding the following goals:

Low learning curve (easy to pick and use).
More efficient than existing tools(faster).
Straight from the web (not a new language or specification, just augment what we have today).
More freedom for the API consumer (allow the consumer to specify exactly what they want).
Predictable query cost (increase consumer awareness and responsibility, related to goal 4).
Don't reinvent the wheel (this really doesn't matter to me, however, it also works as a motivation).

With that in mind, and several proofs of concepts, I thought I could query the APIs using JavaScript as a query language. That's it, without proposing a new DSL. Let's take into account that there are enough specialized query languages for APIs out there, the most noticeable, GraphQL, Falcor, OData, restQL. The intention was just send the JS code to the server à la PostgreSQL DO or Redis eval. It is a crazy idea, but at the same time it became a hard to ignore challenge.

I end up with a TypeScript library for NodeJS and the browser which allows to query API in the following fashion:

const getArticle = func(async (slug: string) => {
  const { name, date } = await BlogApi.getArticle(slug)
  return {
    name,
    date,
  }
})

getArticle('fancy-slug').then(...)

Remote-func not only met the proposed objectives. It also,

Makes end-to-end type safety possible if used with TypeScript.
Allows greater independence between frontend and backend developers.
Can fetch multiple resources at once.
Allows to reduce the data before sending the response to the client.
Can batch and deduplicate requests.
Can stream data from server to client in a single HTTP response, and dispatch in the order of arrival.

And a little more features that you might find useful.

Source code

React Progressive Loader

Yosbel Marín — Mon, 24 Sep 2018 14:31:55 +0000

Defer the load of non-critical images and components if they are off-screen.

This library makes possible to progressively load images, just like Medium does, and React components only when the user is ready to consume the content. Additionaly, take component based code splitting for free. Two at the price of one.

Get it while still hot https://github.com/yosbelms/react-progressive-loader