Message:

Subscribe rss
Blog categories
All | Backendless features
Deployment Models for Business Logic
June 15, 2017 by markpiller

One of the new features we will be releasing in the final update of Backendless 4 beta is support for “business logic deployment models”. This is a new concept introduced in Backendless 4. A “deployment model” combines individual API event handlers, timers and API services into a single group. The purpose of that grouping will become more apparent once we start opening up Backendless Marketplace for submissions, however, the introduction of this feature already opens some very cool features.

This change will be available in the Backendless 4 applications the week of June 19th.

Some important things to keep in mind when working with deployment models:

  • 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 JavaScript “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.

Let’s take a look at how to work with the deployment models:

Creating new event handlers and timers

When creating an event handler or timer in the Backendless Console you will see a new drop-down list where you can select an existing model. To create a new one, simply type in the desired model and click the menu option to create it. The screenshot below is for creating a new event handler. You will see an identical change in the “New Timer” popup:

event-handler-model

The Event Handlers screen in console displays the model name for every handler (see the MODEL column):

multiple-event-handlers

When you download the generated code for event handlers and timers, you need to choose the model for which to download the code. The downloaded code contains only the event handlers and the timers for the selected model:

downloading-model

Similarly, if you were to edit the code directly in the Backendless Console on the CODING screen, you need to choose the language and the model. The displayed tree of directories and files will contain only the code for the selected model:

models-in-coding

For most use-cases, you will find it sufficient to work with the same model. We considered how developers use business logic now and tried to make the developer experience mostly unchanged.

Share this post
Tweet about this on TwitterShare on FacebookGoogle+