Skip to main content
Internal functions can only be called by other functions and cannot be called directly from a Bijection client. By default your Bijection functions are public and accessible to clients. Public functions may be called by malicious users in ways that cause surprising results. Internal functions help you mitigate this risk. We recommend using internal functions any time you’re writing logic that should not be called from a client. While internal functions help mitigate risk by reducing the public surface area of your application, you can still validate internal invariants using argument validation and/or authentication.

Use cases for internal functions

Leverage internal functions by:
  • Calling them from actions via runQuery and runMutation
  • Calling them from HTTP actions via runQuery, runMutation, and runAction
  • Scheduling them from other functions to run in the future
  • Scheduling them to run periodically from cron jobs
  • Running them using the Console
  • Running them from the CLI

Defining internal functions

An internal function is defined using internalQuery, internalMutation, or internalAction. For example:
If you need to pass complicated objects to internal functions you might prefer to not use argument validation. Note though that if you’re using internalQuery or internalMutation it’s a better idea to pass around document IDs instead of documents, to ensure the query or mutation is working with the up-to-date state of the database.

Calling internal functions

Internal functions can be called from actions and scheduled from actions and mutation using the internal object. For example, consider this public upgrade action that calls the internal plans.markPlanAsProfessional mutation we defined above:
In this example a user should not be able to directly call internal.plans.markPlanAsProfessional without going through the upgrade action — if they did, then they would get a free upgrade. You can define public and internal functions in the same file.