When attempting to use the Cognito Identity SDK for JS [github:aws/amazon-cognito-identity-js
] inside an Expo/CRNA app, you’ll soon find out that if calls to Cognito functions like authenticateUser
are very slow, and may not work at all, or cause exp publish
errors (like in my case).
This is due to the fact that Cognito uses slow, expense BigInteger
functions and they happen very slowly or not at all when run in JavascriptCore.
(Please note, it’s not letting me add more than 2 links, so I had to format my URLs a bit oddly.)
There exist projects like this one that allow you to use Cognito more efficiently after ejecting (github:AirLabsTeam/react-native-aws-cognito-js
). And it seems like the Expo team are aware of this issue because (a) an Expo fork of the amazon-cognito-identity-js repo exists at github:expo/amazon-cognito-identity-js
, and (b) the expo-starter-aws app [which may have been abandoned] seems to use Cognito, too (https://github.com/expo/expo-starter-aws/blob/master/cognito-helper.js)
Of course, I’d prefer not to eject at all, but we are locked in to using Cognito for this application since it’s already used by our API and web app. Is it possible at all to either:
- Circumvent the slowness of the BigInteger processing in pure JS
- Create bindings to the device implementations of the
BigInteger.nativeModPow
functions in the Expo SDK so the fork of cognito-identity-js could use it (something like this):
const { computeModPow } = require('expo').Util.BigInteger
Thanks for your time. If this is something Expo accepts pull requests for, I’d be interested in submitting one. Incidentally, there’s a matching feature request for this here, created by another user: AWS Cognito & BigInteger | Voters | Expo