Message:

Subscribe rss
Blog categories

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:

event handler model - Deployment Models for Business Logic

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

multiple event handlers - Deployment Models for Business Logic

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 - Deployment Models for Business Logic

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 - Deployment Models for Business Logic

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.

Posted in Server Code

As we are preparing to launch Backendless 4 out of Beta we need to perform a few maintenance tasks on our servers which will require some downtime. The 4.0 beta cluster will be unavailable on:

May 19th, between 2:00am and 6:00am US Central time (UTC-5)

The 3.x cluster and development console will not be impacted. We apologize for the inconvenience this may cause.

Posted in Status Update

Backendless 4 is a powerful platform that can instantly turn your JS code into an API service. Every declared method (unless it is excluded) gets a dedicated API endpoint accessible via REST and native libraries, which Backendless automatically generates for you. As a developer, you can easily specify what the REST route must look like for every method and you can define the schema for the arguments.

Generated services can be used for multiple purposes. For example, they make it very easy to centralize the business logic for your Backendless app. IoT apps can use the services as the integration points.

Backendless Console gives you a test drive for invoking the services and inspecting requests and responses. Best of all the service code can be written and deployed right from the console. Check out the video below for an overview of Backendless API Services written in JS:

The service code shown in the video is:

Enjoy!

join backendless slack - Join Backendless on Slack

You are invited to join our team on slack, follow the link below to join:
http://slack.backendless.com

See on on Slack!

Posted in Uncategorized

release history v4 - Release history for Backendless 4

We release often and one of the frequent requests we received is the lack of release history. This is changing with Backendless 4, we still plan to release often and now you can see (a very visual) release history for Backendless Cloud and the SDKs at:
https://backendless.com/products/release-history/

Check out the new page and let us know what you think.

Posted in Status

We have published an update for the 4.0 deployment of Backendless – 4.0b3. The update includes the following changes:

  • Fixed problem with developer account confirmation via link in email;
  • Fixed “Login with Twitter” for developer accounts;
  • The “Manage” screen in Backendless console rendered blank in Safari;
  • Fixed error with app deletion;
  • Fixed a bug which caused invocation of unrelated API event handlers on object deletion;

backendless4 banner - Backendless 4.0 in the Cloud has arrived
It is finally here! Backendless version 4.0 Beta 1 is now available in our Cloud! This is a major release packed with some amazing functionality. New management console, generated project templates, online server-side code editing and deployment, AWS lambda integration – these are just some of the new features you will find in version 4. To learn more about version 4, visit the Backendless v4 product page.

Please keep in mind that this is a Beta release and we need to hear from you. If you encounter a problem, please send us an email (support@backendless.com) or post to the support forum.

Enjoy!

If you’re starting an Android project with Backendless and import our SDK library from Maven, please pay attention to the version number of the library. We have published a beta version of the 4.0 SDK into Maven central. When referencing Backendless in Android Studio, version 4 is the default one to popup. Unless you’re building with Backendless version 4 (which will be the default backend in the Cloud very soon), make sure to reference version 3.0.25 of the library as shown in the screenshots below:

Continue reading

This is a question we get very often:

“how can I avoid rejected API calls when my app generates more calls than allowed by the plan’s limit?”

To give you the context of the question – all Backendless plans have a limit of API calls/minute. With the free plan the limit is 300, the Cloud 9 plan provides 600 and the Cloud 99 plan offers 1200 API calls/minute. With the Cloud9/99 plans, the limit can be increased by purchasing function packs which add 600 API calls/minute for each purchased pack. The backend monitors and enforces the limit for each minute, that is if you are on the free plan, Backendless will process the first 300 API calls for any given minute and all other calls above the limit during that minute will be rejected. When the volume of the incoming calls reaches 80%, 90% and 100% of the limit, the system will generate and send out an email informing you that a threshold has been reached.

To avoid rejected calls it is important to monitor performance of your app using Backendless console and stay on top of the notification emails. Backendless Console provides a chart of API calls/minute on the Manage > Analytics > Performance screen. The red line shows the current limit:

api calls minute - API call/minute limit and how to avoid it

As you can see in the image above, the current limit for the app is 1800 API calls/minute and the app’s traffic stays right below the red line.

When you get a notification about the 80/90% threshold, we recommend analyzing the trend of the incoming calls and assessing whether the limit should be increased. It may be a one off occurrence of the traffic spike or a consistent growth of the volume of calls.

 

Posted in Best Practice