Skip to main content

Backend Provider Modules

Quick Answer​

Several core modules exist to keep backend access consistent across apps: src/core/firebase, src/core/aws, src/core/users, src/core/api, and module-level api/index.js files.

Most feature modules support the same pattern: Firebase provider, AWS provider, backend provider, or local provider. Pick one active provider per app and keep the public hook/client contract stable.

Source Map​

src/core/firebase/config.js
src/core/aws/amplifyCompat.js
src/core/users
src/core/api
src/core/helpers

Provider selection also appears inside feature modules:

src/core/chat/api/index.js
src/core/media/index.js
src/core/onboarding/api/index.js
src/core/socialgraph/feed/api/index.js
src/core/socialgraph/friendships/api/index.js
src/core/vendor/api/index.js

Firebase Module​

src/core/firebase/config.js exports shared Firebase handles such as:

export const db = ffirestore()
export const auth = fauth
export const firestore = ffirestore
export const functions = ffunctions

Generated Firebase apps must use their own:

  • GoogleService-Info.plist;
  • google-services.json;
  • Firestore rules;
  • Storage rules;
  • Functions config/secrets;
  • project-specific Function URLs when a module uses direct HTTPS endpoints.

AWS Module​

src/core/aws contains compatibility helpers for AWS/Amplify-backed app variants. Use it only in products that intentionally ship with AWS backend support.

Do not leave both Firebase and AWS active for the same feature unless the app intentionally supports both and has been tested with both.

Users Module​

src/core/users abstracts common user operations:

  • update user;
  • get user by ID;
  • update profile photo;
  • provider-specific user client implementations.

User object shape is shared by onboarding, profile, chat, social graph, notifications, and payments. Changing it affects multiple modules.

Provider Switching Rules​

When switching a feature from Firebase to a custom backend:

  1. Keep the UI exports unchanged.
  2. Implement the same hook/client return shape.
  3. Switch only the relevant api/index.js export.
  4. Remove or isolate inactive provider imports from the active path.
  5. Update tests/smoke checks for loading, empty state, error state, and mutations.
  6. Review security on the backend, not only in the app.

Verification Checklist​

Test after provider changes:

  • app starts logged out and logged in;
  • current user loads;
  • feature list loads with data;
  • feature empty state resolves;
  • create/update/delete mutations work;
  • permission errors show a safe fallback;
  • no inactive provider credentials are required at runtime;
  • release build uses production config, not demo config.

Troubleshooting​

ProblemFix
App imports Firebase after switching providerSearch the active module path for @react-native-firebase imports and isolate them.
Hook returns wrong shapeMatch the Firebase provider contract before changing UI code.
Current user is undefinedCheck onboarding provider, users provider, persisted auth state, and user document reads.
Function URL points to demo projectReplace project-specific URLs and move secrets/config to backend environment.
Build includes unused native SDKsCheck generator flags and package cleanup before release generation.