The idea behind the
@internalOperation directive is to support scenarios where side effects are needed. E.g. after the user logs into the system, you'd like to create a record for them or update the lastLogin field. In this scenario, you're able to accomplish this easily without exposing the mutation to the public API surface.
Other use cases could be that you want to determine if a user is eligible to execute a query or mutation. You could look up in a system if they are allowed to make an action.
This is an example where we upsert the user after a successful login. Upsert means, we create a user object if it doesn't exist yet. If the user exists already, we update the lastLogin field.
Once this mutation is defined, it can be used from within the hooks configuration. Call
client.mutations and the name of the mutation to execute it. That's it, no need to add an ORM, or instantiate a database connection from within the hooks. WunderGraph can handle all the complexity of making all Operations available to the hooks environment.
As you've learned in this section, WunderGraph makes it very easy to make Operations available as typesafe function calls to your hooks environment. Using the
@internalOperation you're able to hide Operations from the public API.