DEV Community: Steve Sanders

Apple App Store review is a nightmare? Try Meta (Facebook/Instagram) app review

Steve Sanders — Tue, 01 Apr 2025 22:11:41 +0000

Apple's App Store review process is pretty notorious for being a nightmare to get through in some situations. There are plenty of horror stories of apps getting rejected for nonsensical reasons or even being rejected during an unrelated update for something that was previously approved. To be fair to Apple, this also happens (perhaps to a lesser extent) with Google's equivalent Play Store review process.

One thing that I love about the web is that it is (for the most part) a truly open platform. For better or worse, developers can publish almost anything they want to the web within minutes. The walled garden in app stores can be an endless source of frustration in comparison. I've experienced this frustration firsthand at a few different companies where I was employed as an engineer in the past. I didn't think that anything could be worse than Apple's App Store review...

...and then I tried publishing a Facebook app.

Exploring Aurora DSQL with TypeScript, Drizzle, Lambda, and AWS CDK

Steve Sanders — Thu, 05 Dec 2024 18:02:47 +0000

Does Amazon's fancy new serverless PostgreSQL-compatible database work with modern TypeScript tooling?

Amazon recently introduced Aurora DSQL in preview:

Amazon Aurora DSQL is a serverless distributed SQL database with virtually unlimited scale, the highest availability, and zero infrastructure management. Aurora DSQL offers the fastest distributed SQL reads and writes and makes it effortless for you to scale to meet any workload demand without database sharding or instance upgrades. With its active-active distributed architecture, Aurora DSQL ensures strong data consistency designed for 99.99% single-Region and 99.999% multi-Region availability. Its serverless design eliminates the operational burden of patching, upgrades, and maintenance downtime. Aurora DSQL is PostgreSQL-compatible and provides an easy-to-use developer experience.

What does all of that mean in practice? DSQL sounds like a truly serverless SQL database - we only pay for what we use and don't need to worry about things like connection pooling. Previous "serverless" SQL database offerings from AWS have left a lot to be desired in terms of both capabilities and cost, so this is a pretty exciting release if it works as promised and the final pricing ends up being reasonable. Let's try it out!

Prerequisites

I'm assuming you have some basic familiarity with the following:

AWS CDK and AWS infrastructure as code
SQL databases
TypeScript
Drizzle ORM

Create AWS CDK project

Let's init a new TypeScript CDK project:

mkdir drizzle-dsql-cdk-lambda && drizzle-dsql-cdk-lambda
cdk init app --language typescript

Create Aurora DSQL Cluster

...and we immediately run into a roadblock. Ideally we would create and manage our DSQL cluster in our CDK project. The CDK compiles to a CloudFormation template to create our AWS resources. Unfortunately Aurora DSQL doesn't support CloudFormation while it is in preview so we will need to create the cluster manually 🤦‍♂️. This is pretty easy to do in the AWS DSQL console with the "Create Cluster" button.

After you've created the cluster, take note of the cluster endpoint as we'll need it in a bit.

Create a Lambda function that connects to the DSQL cluster

We're going to be deploying a Node.js Lambda function that is bundled by esbuild. We need to first add a few dependencies to our project:

npm i esbuild @types/pg -D
npm i @aws-sdk/dsql-signer pg

Add a Lambda function to your CDK stack that looks something like:

const handler = new NodejsFunction(this, 'DSQLHandler', {
  runtime: Runtime.NODEJS_22_X,
  handler: 'handler',
  entry: 'lambda/handler.ts',
  memorySize: 1024,
  bundling: {
    bundleAwsSDK: true,
  },
});

handler.addToRolePolicy(
  new cdk.aws_iam.PolicyStatement({
    effect: cdk.aws_iam.Effect.ALLOW,
    actions: ['dsql:DbConnectAdmin'],
    resources: ['*'],
  })
);

Why do we need that bundleAwsSDK flag if the Lambda Node.js runtime already includes the AWS SDK? Apparently the @aws-sdk/dsql-signer is so new and/or experimental that it doesn't ship with the runtime yet so we'll need to include it in our deployed bundle. For the sake of simplicity the role that we're also giving the function permission to connect to any DSQL cluster - ideally you should lock that down by replacing the resources wildcard with your cluster ARN.

Let's add our Lambda handler code, heavily inspired by an example from the Aurora DSQL docs:

import { DsqlSigner } from '@aws-sdk/dsql-signer';
import { Client } from 'pg';
export const handler = async () => {
  const clusterEndpoint = YOUR_CLUSTER_ENDPOINT;
  let client;
  const region = 'us-east-1';
  try {
    // The token expiration time is optional, and the default value 900 seconds
    const signer = new DsqlSigner({
      hostname: clusterEndpoint,
      region,
    });
    const token = await signer.getDbConnectAdminAuthToken();
    client = new Client({
      host: clusterEndpoint,
      user: 'admin',
      password: token,
      database: 'postgres',
      port: 5432,
      ssl: true,
    });
    // Connect
    await client.connect();
    // Create a new table
    await client.query(`CREATE TABLE IF NOT EXISTS owner (
      id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
      name VARCHAR(30) NOT NULL,
      city VARCHAR(80) NOT NULL,
      telephone VARCHAR(20)
    )`);
    // Insert some data
    await client.query(
      'INSERT INTO owner(name, city, telephone) VALUES($1, $2, $3)',
      ['John Doe', 'Anytown', '555-555-1900']
    );
    // Check that data is inserted by reading it back
    const result = await client.query(
      "SELECT id, city FROM owner where name='John Doe'"
    );
    await client.query("DELETE FROM owner where name='John Doe'");
    return result;
  } catch (error) {
    console.error(error);
    return error;
  } finally {
    client?.end();
  }
};

This handler generates an authentication token, uses the token to connect to the cluster, then executes some simple queries. After building, deploying, and testing your function you should see the Lambda function return the result of the SELECT query.

Add Drizzle

Our Lambda function is currently using raw SQL queries which are not the most fun to write and maintain. Let's replace them with Drizzle ORM, a popular TypeScript ORM.

npm i drizzle-orm

Let's add a simple Drizzle schema to our handler that mimics the database table that we created in the previous step and replace the other queries with the equivalent Drizzle code:

import { DsqlSigner } from '@aws-sdk/dsql-signer';
import { Client } from 'pg';
import { eq } from 'drizzle-orm';
import { drizzle } from 'drizzle-orm/node-postgres';
import { text, pgTable, uuid } from 'drizzle-orm/pg-core';

const owner = pgTable('owner', {
  id: uuid('id').defaultRandom().primaryKey(),
  name: text('name').notNull(),
  city: text('city').notNull(),
  telephone: text('telephone'),
});

export const handler = async () => {
  const clusterEndpoint = YOUR_CLUSTER_ENDPOINT;
  let client;
  const region = 'us-east-1';
  try {
    // The token expiration time is optional, and the default value 900 seconds
    const signer = new DsqlSigner({
      hostname: clusterEndpoint,
      region,
    });
    const token = await signer.getDbConnectAdminAuthToken();
    client = new Client({
      host: clusterEndpoint,
      user: 'admin',
      password: token,
      database: 'postgres',
      port: 5432,
      ssl: true,
    });

    await client.connect();

    const db = drizzle(client, { schema: { owner } });
    await db
      .insert(owner)
      .values({ name: 'John Doe', city: 'Anytown', telephone: '555-555-1900' });
    const owners = await db.select().from(owner);

    await db.delete(owner).where(eq(owner.name, 'John Doe'));

    return owners;
  } catch (error) {
    console.error(error);
    return error;
  } finally {
    client?.end();
  }
};

Much cleaner! For simplicity here I'm declaring the Drizzle schema in the same file. In a real project you will probably want that in a dedicated schema file so that it can be shared and/or used in migrations.

After building, deploying, and testing our function again... it just works!

It's great to see this new service working out of the box with common tooling. This is obviously an extremely simple example but the response time seems quite promising as well.

What About Relationships and Migrations?

I'll write a part 2 of this in the future with a more complex database structure including joins across multiple tables created via drizzle-kit migrations. Aurora DSQL has a pretty extensive list of unsupported PostgreSQL features including foreign key constraints so it should be interesting to see what we can do!

The full code for this project is available on GitHub.

AWS is killing customer AI apps without warning

Steve Sanders — Fri, 08 Nov 2024 04:23:17 +0000

Update Nov 15 2024 - good news! AWS seems to have resolved this issue. I'm seeing quotas restored in my AWS accounts without me doing anything or contacting AWS support.

Amazon Web Services (AWS) has been riding the generative AI hype train hard lately. Roughly one third of sessions at the annual AWS re:Invent conference are currently tagged as AI/ML. That means that AWS must provide some great AI offerings in their massive catalog of services, right?

AWS offers a service called Amazon Bedrock:

Amazon Bedrock is a fully managed service that offers a choice of high-performing foundation models (FMs) from leading AI companies like AI21 Labs, Anthropic, Cohere, Meta, Mistral AI, Stability AI, and Amazon through a single API, along with a broad set of capabilities you need to build generative AI applications with security, privacy, and responsible AI.

That's a lot of buzzwords. In practice, a core feature of Bedrock allows developers to access many models from different providers through a common API. Here's a simple Python example from the Bedrock docs:

body = json.dumps({
    "prompt": "\n\nHuman: explain black holes to 8th graders\n\nAssistant:",
    "max_tokens_to_sample": 300,
    "temperature": 0.1,
    "top_p": 0.9,
})

modelId = 'anthropic.claude-v2'
accept = 'application/json'
contentType = 'application/json'

response = brt.invoke_model(body=body, modelId=modelId, accept=accept, contentType=contentType)

Switching to a different model is as simple as changing the modelId. You do need to request access to each model in the AWS console but that is a pretty simple and quick process. This all sounds great so far, right? It's all fun and games until you start building something and it suddenly stops working.

Disclaimer before the complaining starts: I usually enjoy building software hosted on AWS quite a bit. Any negativity expressed here is coming from a place of me wanting them to do better.

I've been seeing posts on a daily basis across both Twitter/X and the AWS subreddit from users whose Bedrock service suddenly stopped working without warning.

// Detect dark theme var iframe = document.getElementById('tweet-1852007081634664482-381'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1852007081634664482&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1852850212722635156-646'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1852850212722635156&theme=dark" }

AWS manages load on its services by putting quotas on almost everything, which is a completely sensible way to build an outrageously large distributed system. Sometimes these quotas are adjustable (upon request) and sometimes they aren't.

After initially requesting access to a model in Bedrock, a default quota for the model in both requests per minute and tokens per minute will be assigned to your account. AWS has been resetting customer Bedrock quotas to 0. This is happening despite AWS initially granting access to models on Bedrock and assigning a working (non-zero) quota. This causes live customer applications built on top of Bedrock to stop working without any notification whatsoever. For a company that prides itself on "five nines" uptime it is pretty unusual to see something like this. It definitely does not instill a lot of confidence in Bedrock as a service.

This happened to me both in my personal AWS account where I was testing out Bedrock as well as in several AWS accounts belonging to the startup where I serve as CTO and where I was actively building an AI application on top of Bedrock. I've seen varying reports on social media about this getting resolved in a satisfying manner by AWS support. For me, I ended up just switching over to using a provider's API directly rather than waiting several days to hear back from AWS support. In my case this was Anthropic and I haven't had any remotely similar problems with them.

It's not clear if this is all happening because of a bug or if it is something like AWS struggling with capacity to service Bedrock. Either way, it is unacceptable to kill access without warning. At least for now you might want to think twice about building on top of Bedrock.