Mark your calendars, we will be conducting a webinar to talk about Codeless. Get all the information about this exciting technology straight from the source. There will be a technical walkthrough and demos showing how to build with Codeless.

When: Aug 22, 2017, 1:00pm US Central Time
Host: Mark Piller, Backendless founder and CEO

Registration is required. Register now.

The core of the Codeless technology we released last week is the Codeless Logic Designer. It is a visual environment for composing logic of your API/IoT services, Event Handlers, and Timers. The system uses “blocks”, a jigsaw puzzle-like UI components placed into categories. When you create a codeless service, you snap blocks to create the logic. As you do it, Backendless automatically generates the source code which will be executed once the logic is deployed. Check out the video below for an overview of the Codeless user interface:

With the release of Backendless Cloud v4.1.0 we added an amazing new feature called Codeless Programming. Using Codeless anyone can develop in Backendless without any knowledge of a programming language. The environment is fully visual and lets you create API/IoT Services, Backendless API Event Handlers and Timers. The system can be used to create programs of any complexity. Created logic can be deployed to become an instant API service accessible via REST API as well as dynamically generated native SDKs.  Codeless programs can be either independently standing services or can extend and enhance a Backendless application.

With the recent update of the Backendless service (version 4.0.8) you can now add your app’s icon and the appstores links in Backendless console. This is done so we can make it easier for you to identify the app and also to help us build a gallery of apps powered by Backendless. We are also planning to provide templates for your app’s web-based home page to help you market your Backendless apps.

When you login to console, you will see a form where you can upload the icon and enter the URLs for Apple’s and Google app stores.

Quite often you need to run a test query or send an API request to see the server response. Our REST docs show examples using curl , but at times it may be inconvenient. You may need to play with the API request arguments, change the body, etc and modifying your curl  command is not as straightforward. To make it easier, we create a collection of our APIs for Postman. If you are not familiar with Postman, it is a desktop tool that lets you run API requests, see the server responses, you can easily change the endpoint URLs, request headers and body. Adding our APIs collection into Postman is now as simple as a click of a button because that button is integrated directly into Backendless Console. Check out the video below for an overview of the integration.

We are happy to announce that Backendless 4 has been released out of Beta. It is now the default environment and all new apps are created in version 4. Now that the Beta is over we have enabled billing in version 4 and you can choose a pricing plan for your application. This can be done using the Manage > Billing section in the Backendless Console. There are four pricing plans to choose from. The details of the plans can be found on the Backendless Cloud Pricing page.

We have introduced a few changes:

• There is now a free, 14 day trial of the Cloud99 plan. If you created an app while Backendless 4 was in beta, the trial has also been enabled for it. When the trial is over, the app is switched to the Free plan.
• The “Development team” feature is now enabled for all plans, including the free one. It means you can invite other developers to your app regardless of the plan it is on.
• We have increased the “Cloud Code Deployment Size” limit for all plans. This is the cumulative size of all the code and dependencies it uses in megabytes. The new limits are 5mb for the Free, Developer and Cloud9 plans and 10mb for the Cloud99 plan.
• We have completely removed the limit for the number of push notifications in the Cloud99 plan.

We would like to thank everyone who helped us with 4.0 beta. We are very excited about the release and have a lot of very cool features in the works.

If you have an app in 3.x:

We will continue running the 3.x environment, however, we encourage you to migrate your app to 4.0. The free plan in 3.x will be available until November 1st, 2017. After then, the plan will be discontinued. Applications on the free plan in 3.x would either need to migrate to 4.0 or switch to a paid plan before November 1st.

If you have any questions, please contact us on the support forum or the Slack channel, we will be happy to assist you.

We have had a very successful beta release and received a lot of positive feedback. We would like to thank everyone for your contribution which helped us make the product better than ever.

As we are preparing for the GA release of 4.0, there are changes which may affect your apps. Please see the list below:

1. All Github repositories for our SDKs will be updated where the current “4.0” branches will become “master”.
2. Both JS SDK and JS CodeRunner for version 4.0 will be released into NPM.
3. Plan limits and billing will be turned on for Backendless 4.
4. Any new app created in 4.0 after it goes GA will be on a 14 days trial for the Cloud99 plan, after that, it will switch to the free plan.
5. All existing apps in 4.0 will also be switched to the Cloud99 trial. Once it runs out (14 days), the app will go to the free plan and you will need to assess if it should be upgraded to a paid plan. If the app’s usage of the backend resources exceeds the limits of the free plan, you will receive an email notification.
6. We will continue running the 3.x backend. If you have an app on the free plan in 3.x you would either need to migrate to 4.0 before November 1st, 2017 or switch it to a paid plan in 3.x.

If you have any questions, please contact us on the support forum or the Slack channel.

With the introduction of Deployment Models for business logic (Cloud Code), we also added support for “invocation chains”. This is an ability to chain together multiple server-side event handlers registered to process the same event. Previously, you could inject cloud code into the API invocation flow as shown in the image below:

For any API call, you could have only one before/after event handler with your own custom business logic. This is changing with deployment models and you can have multiple event handlers chained together:

This is a HUGE improvement. It promotes better design for cloud code with a clean division of responsibilities between the event handlers. It is important to note that any data received as arguments for an API call is passed from one event handler to another. If an event handler sitting at the beginning of the chain makes a change to an argument (or the return value), then all other event handlers down the chain will get the modified value.

Setting up chains in console

A question you might be asking is how to configure the order of the event handlers. This is done in the Backendless Console. Consider the following example:

As you can see there are three "beforeCreate"  event handlers for the "*"  context (which means they apply to every data table). When Backendless detects you have more than one event handler applicable to a particular context, it displays the “handler ordering” icon:

Clicking the icon opens up a popup where you can control the execution order for all applicable event handlers:

We’ll have a video posted to our YouTube channel with a demo of the functionality soon. That’s all for now, guys. Happy coding!

We are preparing one of the final Beta builds for Backendless 4. The build should be released early in the week of June 19th. We plan to release the service out of beta shortly after that. One of the important changes in the upcoming service update will be the introduction of deployment models. When the service is updated with that build, it will be necessary to redeploy your business logic (API Services, Event Handlers, and Timers) using the latest release of CodeRunner. If you do not do that, any existing business logic in the Backendless 4 apps will stop working.

We realize it is going to cause an inconvenience – we really wanted to avoid it. However, the service is in beta and we thought you’d cut us some slack.

If you have any questions about this, please ask either on the support forum or our slack channel.

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:

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

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:

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:

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.