Where is this published

[nikwotton]

I see you have commits quite recent on this and I saw this X post But when I check npmjs I see there hasn't been a new version published in a year. Is this published somewhere else?

[sam-goodwin]

Hi @nikwotton we haven't published a stable release. The 1 year old version is from a previous attempt pre-effect. A version will be available this week.

[richarddd]

@sam-goodwin First, I want to acknowledge that Effect is an great architectural choice for this project, given the reduction of boilerplate. However, making Effect a core dependency might limit broader adoption of the library, as not all teams are ready or willing to embrace this pattern in their projects, despite its benefits.

Would you consider splitting itty-aws into two versions? We could have a base non-Effect version where retry/HTTP mechanisms are either configurable by the caller or provided with sensible defaults. Then, itty-aws/effect could be offered as a separate package that internally uses the non-Effect version but adds the Effect-specific functionality.

This approach would maintain the benefits of Effect for teams that want it while making the library more accessible to those who prefer different patterns.

[sam-goodwin]

Just published 0.2.0 to NPM and set up CI/CD. We will maintaining a changelog and regular releases going forward.

https://www.npmjs.com/package/itty-aws

Our primary focus is on Effect right now as part of our ongoing research to generate Alchemy IaC resources with Effect + AI.

RE: a Promise interface, I was thinking that we would still use Effect underneath and instead expose a Promise interface on top that simply runs Effect.runPromise. We plan to use Effect deep in the internals to drive retries, exponential backoffs, etc. and I'd rather not reproduce that logic in a non-Effect way.

What do you think about this experience?

import S3 from "itty-aws/s3";

const client = new S3({ mode: "async" })

const bucket = await client.createBucket({ .. })

We can then (at the type-level) transform the Effect-based clients into Promised by stripping the errors:

type AsyncClient<C> = {
  [api in keyof C]: (...args: Parameters<C[api]>): Promise<
    ReturnType<C[api]> extends Effect<infer Out> ? Out : never
  >
}

Is your request about not having Effect in the set of dependencies or just expressing the need for an async client for non-Effect users?

We have a lot of work to do to optimize itty-aws's bundle size after adding support for all protocols, but are committed to making itty-aws the smallest possible AWS client in JS.

[richarddd]

Thanks for the feedback and reply.

We plan to use Effect deep in the internals to drive retries, exponential backoffs.

Again, i truly appreciate and understand the value this brings (in terms of simplicity) but this is a one time implementation as all clients share the same connection, retry, timeout logic etc.

My point is, as illustrated by the effect website:, that even though we can implement this with only a few lines of code in effect.

httpClient.get("...").pipe(
    Effect.andThen((response) => response.json),
    Effect.timeout("1 second"),
    Effect.retry({
      schedule: Schedule.exponential(1000),
      times: 3
    })

This is a one off thing and maybe doesn't justify bringing in an entire library :)
Additionally, aws4fetch already implements retries with exponential backoff with full jitter strategy by default.

PS. I think the latest deployment failed:
https://www.npmjs.com/package/itty-aws?activeTab=code