Type definition for tables()._db, tables()._doc is wrong for nodejs18.x runtime about functions HOT 10 OPEN

I've just lost a chunk of time to this - pretty knotty thing to fix but at the very least it would be useful to add a comment to tables.d.ts to indicate that _db and _doc may be the incorrect type depending on the version of node in use.

Happy to chip in with the fixes if that'd be useful.

from functions.

@TheWarBadger @lpsinger PRs def welcome! /cc @tbeseda

from functions.

Oh yikes. I hadn't thought about these types inherently changing based on the Node runtime.
Architect functions provides compat between AWS SDK v2 and v3 based on what's available in the Lambda now.

I don't use these types on the daily, so any ideas around how we might change the usage pattern here is welcome. Like is it easier to manually annotate types from specific imported types? as opposed to the implicit types provided when referencing arc.tables()

Or maybe arc/fns implicitly types with SDK v3 but provides v2-based types that can be imported for handlers in Node14-16?

from functions.

What about providing two different type packages, one for AWS SDK v2 and one for AWS SDK v3?

from functions.

Or templating the types so that you can do await tables<2>() or await tables<3>?

from functions.

@Ipsinger sounds good, I would suggest extending the API with some sensible run time protections - E.G. tables_sdk3() (or some Template equivalent) which throws a runtime exception with a useful message like trying to use AWS sdkv2 but Architect uses v3 when running on Node18. That way if someone upgrades their node version they get an immediate sensible error (including an unspecified version for people who don’t need the lower level API).

That said, I won’t be able to check this for a couple of days due to being AFK, but if using a type Union of DynamoV1 | DynamoV2 (class names are wrong but you get the idea) for the existing _doc etc is feasible then it would force the user to do their own type guards. Not as elegant but also gets the job done.

from functions.

@Ipsinger sounds good, I would suggest extending the API with some sensible run time protections - E.G. tables_sdk3() (or some Template equivalent) which throws a runtime exception with a useful message like trying to use AWS sdkv2 but Architect uses v3 when running on Node18.

What if the user is using a custom Lambda runtime that has node 16.x but the AWS SDK v3 installed? It would be better to attempt to import the V3 SDK and fall back to the V2 SDK if it is not installed.

from functions.

What if the user is using a custom Lambda runtime that has node 16.x but the AWS SDK v3 installed?

I would say that is not a use case we currently intend to support. It could be done, but it would add a fair bit of complexity for something that is, as far as I can tell, theoretical. I've yet to field a report of an Architect user doing this fwiw!

from functions.

A custom Lambda runtime is something that I have contemplated with my project.

from functions.

Use of Architect Functions in custom runtimes is totally fine and an intended use case! I'm referring specifically to a custom runtime where:

1. The version of Node.js in 16 (which is maintenance / scheduled to go EOL in a few months), and
2. It's paired with the current version of the AWS SDK (v3), which would not conform to the Lambda's convention of pairing Node + SDK versions in production (<=16 = SDK v2, >=18 = SDK v3)

While inadvisable, there nothing fundamentally impossible or wrong with that approach, but it is an obscure set of circumstances that I don't think we need to support.

Probably more likely would be a custom runtime that uses the active version of Node.js (18), or a higher version, that would be paired with the current AWS SDK (v3).

from functions.