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:
Check out the new page and let us know what you think.
We have published an update for the 4.0 deployment of Backendless – 4.0b3. The update includes the following changes:
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 (firstname.lastname@example.org) or post to the support forum.
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:
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:
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.
The backend for your Backendless app sends out emails for the following events:
The default email address used by Backendless is email@example.com, which is an automated account – we do not actively monitor incoming emails there. If you do not change the email address in your Backendless account and a user replies back to any of the emails listed above, the response goes back to the inbox for our automated account.
We see a lot of applications which are published to app stores where email address is not changed. As a result, you are missing direct communication received from your users. To avoid this, it is recommended to change the email address per the instructions in our documentation.
The version 4 of Backendless is getting quite close to be released in Backendless Cloud. We are in the final stages of testing and it should not take very long for you to see and experience the new version online. The initial release of 4.0 in the Cloud environment will be a Beta. We anticipate to keep 4.0 in Beta for about a month. During the Beta, you will be able to create new apps in both the 3.x (the current release) as well as the 4.0 environments. We added a nice backend version toggle so you will be able to switch between the version.
Once the 4.0 is released out of Beta, it will be the default version and all new apps will be created in version 4. If you have an app in 3.x, you will still be able to run it there.
I am very excited about version 4, it is quite an enjoyable product. I am sure you will share that opinion with me once you try it out.
Please stay tuned for more updates.
p.s. the future is Codeless..
One of the new features we added in Backendless 4.0 is support for custom code generators. We already have multiple code generators which can create complete client-side projects for Android, iOS and JS with just a few button clicks. Ability to add your own custom generators greatly expands the possibilities.
The Backendless code generator system uses XSLT. A code generator is a combination of XSLT scripts and some static content. The scripts are responsible for the dynamic content. To demonstrate how to create a code generator I put together an example which creates a diagram for the data tables in your Backendless app. You can see a demo of the example as well as the process I followed in the video below:
With the introduction of version 4.0 in the Backendless Cloud environment, we set the goal to allow both the current version of 3.x and the new 4.0 to collocate on the same subdomain. When we introduce 4.0 in the Cloud, both versions of the backend will be available on the https://develop.backendless.com domain. As a result, there is going to be a change for the Admin and Management API. The change will require the /3.x prefix to be added to all API routes except for “Developer Login”. For example, the following route:
would need to be modified as shown below:
This change will go in effect when the 4.0 version becomes available in the Cloud. There will be an additional blog post 24 hours before the release is switched on.