Skip to content

About Deployment Models

A “deployment model” combines API event handlers, timers and API services into a single group. The purpose of that grouping is to allow "fragmented" deployment of the business logic into the application. For example, you could separate the API services code from the event handlers and timers in separate projects and deploy them independently of each other.

It is important to keep the following in mind when working with business logic:

  • Deployment models are associated with languages. It means a model with the same name may exist with Java business logic and JS business logic, but it is not the same model – they will contain different business logic.
  • A model cannot contain more than one API event handler attached to the same "asset", which is a table/file/messaging channel. This means, for instance, if you have a "afterUpdate" event handler processing events for the "Person" table and the event handler is in model “X”, the same model “X” cannot have another "afterUpdate" handler for the table "Person".
  • Contrary to what’s stated above, you can have the same kind of an API event handler in different models.
  • When downloading code from the Backendless Console, you must identify the language and then the model for which to download the code.
  • When deploying code using CodeRunner (JS or Java), the deployment model name for the code must be specified either in the CodeRunner's configuration file or from the command line.
  • Deploying code into a model deletes all previously deployed code in the same model.
  • When the code is debugged locally (while being plugged into the Cloud servers), it takes precedence over the same code which may have been previously deployed. In other words, the Debug mode has higher precedence than the Production mode.