lobo/aws-sdk-for-zig
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
AWS SDK for Zig
33 Commits 7 Branches 2 Tags 20 MiB
Zig 99.9%
Makefile 0.1%
c6dbbf33af
Go to file
Emil Lerch c6dbbf33af
allow different endpoing/sigv4 service names 
This seems silly, but I guess in AWS it is a thing that these two values may
be different. Consumers of awshttp have the option of ignoring this, which
should be correct most of the time. Aws.zig will, however, use the service
metadata to do the right thing
2021-06-09 16:25:49 -07:00
src allow different endpoing/sigv4 service names 2021-06-09 16:25:49 -07:00
.gitignore update .gitignore for generated files 2021-06-09 16:16:54 -07:00
build.zig update build.zig with zig 0.8.0 instructions 2021-06-09 16:18:01 -07:00
Dockerfile switch openssl->aws-lc 2021-04-29 16:27:23 -07:00
LICENSE first thing that actually works 2021-04-27 11:24:01 -07:00
Makefile first thing that actually works 2021-04-27 11:24:01 -07:00
README.md update TODOs in README 2021-05-29 19:46:46 -07:00

README.md

AWS SDK for Zig

Ok, so it's not actually an SDK (yet). Right now this is SDK supports sts get-caller-identity action only. Why? Because it's one of the easiest to support, so I started there. From here, the next major step is to codegen the types necessary to support the various services. Currently this code is dynamically generating the sts types so we are somewhat codegen ready, but current comptime limitations might trip us up. The advantage of comptime is that only types actually used would be generated vs the whole surface area of AWS. That said, with most of the heavy lifting now coded, the addition of the request/response types, even if all of them are added, should not balloon the size beyond "reasonable". Of course this still needs to be be seen.

This is my first serious zig effort, so please issue a PR if the code isn't "ziggy" or if there's a better way.

This is designed to be built statically using the aws_c_* libraries, so we inherit a lot of the goodness of the work going on there. Implementing get-caller-identity with all dependencies statically linked gives us a stripped executable size of 5.3M for x86_linux (which is all that's tested at the moment).

Building

I am assuming here that if you're playing with zig, you pretty much know what you're doing, so I will stay brief.

First, the dependencies are required. Use the Dockerfile to build these. a docker build will do, but be prepared for it to run a while. Openssl in particular will take a while, but without any particular knowledge I'm also hoping/expecting AWS to factor out that library sometime in the future.

Once that's done, you'll have an alpine image with all dependencies ready to go and zig 0.7.1 installed. The build.zig currently relies on this PR to allow stripping -static, so either:

  • Modify build.zig, then strip (or not) after the fact
  • Install make and use the included Makefile

Running

This library uses the aws c libraries for it's work, so it operates like most other 'AWS things'. Note that I tested by setting the appropriate environment variables, so config files haven't gotten a run through. main.zig gives you a program to call sts GetCallerIdentity. For local testing or alternative endpoints, there's no real standard, so there is code to look for AWS_ENDPOINT_URL environment variable that will supercede all other configuration.

Dependencies

Full dependency tree: aws-c-auth

  • s2n
    • aws-lc
  • aws-c-common
  • aws-c-compression
    • aws-c-common
  • aws-c-http
    • s2n
    • aws-c-common
    • aws-c-io
      • aws-c-common
      • s2n
        • aws-lc
      • aws-c-cal
        • aws-c-common
        • aws-lc
    • aws-c-compression
      • aws-c-common
  • aws-c-cal
    • aws-c-common
    • aws-lc

Build order based on above:

  1. aws-c-common
  2. aws-lc
  3. s2n
  4. aws-c-cal
  5. aws-c-compression
  6. aws-c-io
  7. aws-c-http
  8. aws-c-auth

Dockerfile in this repo will manage this

TODO List:

  • Implement jitter/exponential backoff. This appears to be configuration of aws_c_io and should therefore be trivial
  • Implement timeouts and other TODO's in the code
  • Implement error handling for 4xx, 5xx and other unexpected return values
  • ✓ Implement generic response body -> Response type handling (right now, this is hard-coded)
  • ✓ Implement codegen for services with xml structures (using Smithy models)
  • ✓ Implement codegen for others (using Smithy models)
  • Switch to aws-c-cal upsream once PR for full static musl build support is merged (see Dockerfile)
  • Remove compiler 0.7.1 shims when 0.8.0 is released (new 2021-05-29. I will proceed in this order unless I get other requests)
  • Implement AWS query protocol. This is the protocol in use by sts.getcalleridentity
  • Implement AWS Json 1.0 protocol
  • Implement AWS Json 1.1 protocol
  • Implement AWS restXml protocol
  • Implement AWS EC2 query protocol

Compiler wishlist/watchlist:

This is no longer as important. The primary issue was in the return value, but due to the way AWS responses are provided, we are able to statically declare a type and thus allow our types to be generated.