lobo/aws-sdk-for-zig
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
AWS SDK for Zig
72 Commits 7 Branches 2 Tags 20 MiB
Zig 99.9%
Makefile 0.1%
dfa0be60b9
Go to file
Emil Lerch dfa0be60b9
Some checks failed
continuous-integration/drone/push Build is failing
Details
update code generation without containing struct 
Instead we will rely here on the implicit struct provided by the file
itself. This means that when the service_manifest.zig import is
assigned, we don't end up with a construct like "manifest.sts.sts" to
get to the sts service. This simplifies greatly the way that
servicemodel.zig needs to behave.

One down side, however, is that the structure does not seem
accessible with the current zig language, making metaInfo unable
to access itself as it did before. Or maybe it can, I just can't find
it. So, this change also adds a new "service_metadata" public constant
with the same declarations being published at the file level, and
that is the new return from the metaInfo function. Our aws.zig
only really needs the action and that metadata, so we're ok with that
even if there is some duplication (we could codegen pointers over, and
maybe should to save a little bit of space).
2021-06-30 13:40:20 -07:00
codegen update code generation without containing struct 2021-06-30 13:40:20 -07:00
smithy extract smithy to separate package 2021-06-30 09:05:21 -07:00
src update code generation without containing struct 2021-06-30 13:40:20 -07:00
.drone.yml perform build before test/add gen as a dependency for test 2021-06-30 11:09:30 -07:00
.gitignore extract smithy to separate package 2021-06-30 09:05:21 -07:00
build.zig move install to end 2021-06-30 11:13:12 -07:00
Dockerfile update Dockerfile for 0.8.0 2021-06-12 09:33:58 -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 add build badge to README 2021-06-30 11:04:03 -07:00

README.md

AWS SDK for Zig

Build Status

Ok, so it's not actually an SDK (yet). Right now the SDK should support any "query-based" operation and probably EC2, though this isn't tested yet. Total service count should be around 18 services supported. If you use an unsupported service, you'll get a compile error.

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. Current executable size is 10.3M, about half of which is due to the SSL library. This is 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 master installed. There are some build-related things still broken in 0.8.0 and hopefully 0.8.1 will address those and we can be on a standard release.

  • zig build should work. It will build the code generation project, run the code generation, then build the main project with the generated code.
  • Install make and use the included Makefile. Going this path should be fine with zig 0.8.0 release, but code generation has not been added to the Makefile yet (ever?), so you'll be on your own for that.

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 upstream once PR for full static musl build support is merged (see Dockerfile)
  • Move to compiler on tagged release (hopefully 0.8.1) (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. Total service count 18
  • Implement AWS Json 1.0 protocol. Includes dynamodb. Total service count 18
  • Implement AWS Json 1.1 protocol. Includes ecs. Total service count 105
  • Implement AWS restXml protocol. Includes S3. Total service count 4.
  • ✓ Implement AWS EC2 query protocol. Includes EC2. Total service count 1.

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.