Remove dependency on Foundation

[pokryfka]

Is your feature request related to a problem? Please describe.
Dependency on Foundation affects significantly cold start.

Describe the solution you'd like

• Remove dependency on any Foundation types like Date and Data.
• Extend API to be able to provide custom JSON encoder/decoder.

Additional context

• cold start of lambda is ~0.3s faster without Foundation, decoding Event without any date formatters/decoders, difference increases when statically linked;
  Performance documentation awslabs/swift-aws-lambda-runtime#79 (comment)

• Foundation JSON encoder/decoder has terrible performance on Linux, see Consider replacing Foundation JSON encoder awslabs/swift-aws-lambda-runtime#153 (comment), changing will improve performance of AWSSDKSwift not only during cald start

• It is relatively easy to use custom JSON encoder and remove dependency on Foundation when using Swift AWS Lambda Runtime

• It is not possible not to link Foundation when using AWSSDKSwift,
  see Invocation time longer than expected on cold starts awslabs/swift-aws-lambda-runtime#163

[pokryfka]

CC @fabianfett

[adam-fowler]

I think you need to break this up into separate tasks. This is a huge task which would require us to replace

URL, Date, DateFormatter, NSRegularExpression, JSONEncoder, CharacterSet, UUID, ContiguousBytes, DataProtocol

You would also need a FoundationCompat library to provide the interfaces that require Foundation. eg AWSPayload conversion to and from Data

One thing that might hold all of this back though is swift-crypto pulls in Foundation, I'm not sure how you want to resolve that one.

There is an argument for doing some of this work still. We could look at replacing the JSONEncoder. I'm sure @fabianfett would be really keen on this.

[fabianfett]

One thing that might hold all of this back though is swift-crypto pulls in Foundation, I'm not sure how you want to resolve that one.

Same is true for AsyncHTTPClient

There is an argument for doing some of this work still. We could look at replacing the JSONEncoder. I'm sure @fabianfett would be really keen on this.

I think it would be enough to make the default JSONEncoder and JSONDecoder replaceable.

Also I have an offering to replace UUID: https://github.com/fabianfett/swift-extras-uuid

[adam-fowler]

Same is true for AsyncHTTPClient

Good point. Removing Foundation from AHC would be a good starting point but someone needs to do an implementation of Date first and that would be a huge undertaking. And getting SSWG to accept it would be even harder.

I think it would be enough to make the default JSONEncoder and JSONDecoder replaceable.

Should be easy enough.

Also I have an offering to replace UUID: https://github.com/fabianfett/swift-extras-uuid

You can go ahead, although given we can't remove Foundation in the foreseeable future is this necessary? What do we gain, except less exposure.

[pokryfka]

@adam-fowler @fabianfett

thank you for your feedback and identifying the main problems.

Good point. Removing Foundation from AHC would be a good starting point but someone needs to do an implementation of Date first and that would be a huge undertaking. And getting SSWG to accept it would be even harder.

Had a (very) quick lock at AsyncHTTPClient and it seems:

• it uses Date only to write expires Cookie value (always in the same format and in UTC),
• URL to parse schema and host
• Data in 2 (convenience) functions

So technically its some work but probably not a huge effort - dumping a timestamp is much smaller task than rewriting Date;
I will play with in spare time (low priority), this should give me a better understanding of the "not using Foundation" challenges.
I understand that such PR could be never approved...

[adam-fowler]

I understand that such PR could be never approved...

I wouldn't be so sure of that. If you can produce a PR which removes Foundation I think there will be people sympathetic to it.

[adam-fowler]

swift-server/async-http-client#299