Open kjhickman opened 1 month ago
We currently do not have Native AOT support on our roadmap. We welcome contributions, but we would like to better understand what goals/expectations you have from Native AOT support. What benefits/features are you expecting to be unlocked with Native AOT support? Does the lack of Native AOT support currently prevent you from using the driver?
Since Native AOT-published apps can startup so much faster with a smaller memory footprint, they're great for serverless apps. With Fauna being a serverless database, it does lend itself to being used in a serverless context as well, but currently it's not usable at all for Native AOT.
In my case, a serverless function cold-start duration can be drastically reduced with AOT. I have a strict time constraint for quickly the function must run, so Native AOT is basically a requirement.
sorry for delayed response @kjhickman. It'd be awesome if you can cut a PR. Can you also let us know which platform(s) you are targeting? This will help us better understand the context and provide better guidance.
I was curious if NativeAOT-support is something being considering for a future release.
In my own testing with this package I found just two places I believe to the the problem for AOT.
JsonSerializer.Deserialize<JsonElement>(body)
is called without passing in aJsonTypeInfo<T>
insideQueryResponse.GetFromResponseBody<T>()
andEvent<T>.From()
. For now even without resolving this, these methods could be decorated with[RequiresUnreferencedCode("some message")]
to signal that they won't work with AOT.If not, I'd be interested in possibly taking a stab at adding support for NativeAOT myself. Could you provide guidance on whether this would be a welcomed contribution, or if there are any specific challenges or considerations that should be kept in mind?