Comments (15)
What's wrong with using the NIOPHTTP1 versions of these objects, they are already imported by AWSLambdaRuntimeCore?
from swift-aws-lambda-runtime.
nio's versions are a bit different from the ones in AWSLambdaEvents, the latter are designed for JSON payload decoding/encoding
we could consider adding a prefix to more easily disambiguate.
from swift-aws-lambda-runtime.
I'd add prefixes too.
from swift-aws-lambda-runtime.
@weissi Do you have any recommendations in mind?
from swift-aws-lambda-runtime.
ALR*
[A]WS [L]amba [R]untime? Maybe you already have some sort of common prefix? In SwiftNIO of course we use NIO
for that purpose.
from swift-aws-lambda-runtime.
Of course that makes the type names a bit ugly. How are the users most commonly interfacing with those types?
from swift-aws-lambda-runtime.
normally we namespace under the Lambda
from swift-aws-lambda-runtime.
sounds good Lambda*
?
from swift-aws-lambda-runtime.
well i'd put them in Lambda.*
then
but that's not really the point since they are not connected to the lambda runtime but to the aws event. Maybe we should namespace them in AWSHTTPTypes
. But this could also create a naming conflict with the AWS SDK.
from swift-aws-lambda-runtime.
@fabianfett There isnt any AWSHTTPTypes
and I'm not intending to add any. Even if I did, we'll be able to discriminate between them using the framework name. I'm trying to use the NIO types as much as possible
from swift-aws-lambda-runtime.
the latter are designed for JSON payload decoding/encoding
what? :-)
Apart from all the duping, wouldn’t you want to use the NIO types in the public API?
(not that this is necessary, but if you want, you could still use those types internally)
This is not about things like a V2.Request but about the basic http types.
Note that this even has functional implications (and duping), e.g. header lookup is not CI?
from swift-aws-lambda-runtime.
@helje5 IIRC the main issues was that we would need to be extending these types to add functionality to them (Codable conformance mainly IIRC). rule of thumb we have been following in library development is to avoid extending public types from other libraries (SwiftNIO in this case) as it may lead to conflicts with other libraries that may do the same.
from swift-aws-lambda-runtime.
You don't need to extend the types to decode them (yes, Codable can only be added to the original type itself, but that is not required here). You can decode the necessary data in init(decoder:) and then construct the actual model. Kinda similar to this:
As mentioned in the Slack, a reasonable argument for the duping is that NIO isn't actually necessary for Lambdas. Don't know.
from swift-aws-lambda-runtime.
You don't need to extend the types to decode them (yes, Codable can only be added to the original type itself, but that is not required here). You can decode the necessary data in init(decoder:) and then construct the actual model. Kinda similar to this:
I guess if we decide to adopt the NIO types after all we could also use property wrappers
As mentioned in the Slack, a reasonable argument for the duping is that NIO isn't actually necessary for Lambdas. Don't know.
that too. personally, I don't love leaking types where not necessary. there is the argument of copying so we need to trade that off
in the case of HTTPHeaders, there is also a set of mutability functionality that comes with that type that may not makes sense to expose in the Lambda request use case which is more immutable in nature
from swift-aws-lambda-runtime.
there is the argument of copying so we need to trade that off
They are not even plain copies, e.g. the AWS method is a struct (which is actually the better choice), while the NIO one is an enum w/ an associated type. It's crap and weird if you need to convert them back.
Wrt HTTPHeaders, the NIO ones are actually better than the plain Dict you have in AWS because the latter doesn't account for the header case insensitivity.
Yes, AWS breaks out headers in weird ways (single/multi value), but there is no real reason to not combine them back into NIO headers after decoding.
I don't get the mutability thing. NIOHeaders are a regular CoW struct just like Dictionary, right?
In the end it really depends on whether you consider NIO a must have dependency or not. If it is, it's weird not to use its HTTP header types. If not (and they are good arguments for dropping it IMO for this specific thing), I think it's OK to keep it the way it is.
from swift-aws-lambda-runtime.
Related Issues (20)
- Plugin does not work HOT 4
- [plugin] Provided Examples' Package.swift does not work with the archive plugin. HOT 2
- [plugin] LocalDebugging example - archive fails because of Shared code HOT 3
- Replacement for Lambda.run? HOT 5
- How to fix newline in input causing Swift AWS lambda to fail in localhost testing HOT 2
- README.MD example about SimpleLambdaHandler HOT 3
- Archive plugin execution error with AWS SDK HOT 14
- Discussions repository Feature HOT 5
- Archive plugin to generate libraries (*.so) HOT 2
- [Request] Support Serverless Framework with a plugin? HOT 6
- [Idea] Could Lambda Layers Custom Runtime improve cold start performance? HOT 3
- [Feature Request] Somehow don't touch Package.resolved during lambda package archive to work better with VSCode. HOT 1
- [BUG] Can't compile code with NSFileCoordinator (cannot find in scope) HOT 3
- CI builds fails with Swift 5.9 and Swift nightly HOT 4
- [Question] Can DocC remove license headers from source code file HOT 4
- Add support for SPM Resources HOT 1
- print statements do not work despite context.logger.info(stringLiteral:) working HOT 1
- Debugging locally on a different invocation endpoint HOT 3
- Function crash details not reported HOT 6
- Event JSON HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from swift-aws-lambda-runtime.