Sometimes (or in some cases, every time) when you invoke a custom API Service, you may need additional information about the context from which the HTTP request was sent/received, such as user or device information. To collect that information, we provide a class called InvocationContext .
Today we’re going to take another look at security configurations in Backendless. In this article, we will talk about how to restrict direct access to your data via API and only expose your custom API endpoints. This does not mean you should use some other set of “admin” APIs for data management. Instead, it is accomplished by setting up proper security settings.
Backendless provides ways to set up really granular permissions for your resources, including even row-level security in your data tables. But for this task, we’re only going to need system roles and global permissions. Thus, it won’t require you to do a lot of configurations or create additional assets, such as custom roles.
Have you ever wondered why is it often so tedious so make your simple Java app a web server, with the methods becoming the endpoints? You need to add libraries, write additional “web” wrappers, set up a server and a hosting, configure load balancing and much, much more. Do you really have to go through all these things when you just want this piece of code be available via the Web so that others can invoke it and get some fancy results?
The good news is that nowadays this is much less of a problem: with services like Backendless, it is easy to transform your custom code into a real REST service available via both REST and JS/iOS/Android/Java APIs. If needed, authentication also comes available out-of-the-box. It is worth noting that this is all for no charge except for the number of API services you may have and the number of API calls you’ll make to the service in a month.
In this article, we’ll show you how to make your HelloWorld app really say Hello to the whole World.
In a previous article (How to Save an Object with All the Children in a Single Call to Server), we examined how to simply save an object model. However, Backendless custom services give us much more flexibility when it comes to saving objects. In this article, we are going to cover how to perform complex business logic actions such as saving an object with calculated information in one API call using custom services. As we’ll demonstrate in this example, you can actually encapsulate entire portions of your business logic on the server side.
For this example, we will build a custom service that will emulate the order process for an automotive technician service station.
From time to time, we see some developers struggle with understanding the principles of asynchronous work with Backendless. In this post we’ll try to shed more light on this aspect: describe what async calls are, why you need them and how to properly perform such calls and process the results. This post will be specific to Java and Android, but most of the principles apply to any language and environment.
If you’ve worked with Backendless API for a while, you may occasionally run into a situation where the functionality you’d like to have isn’t readily available. One such function is the programmatic management of your application’s data tables. For instance, you may need to clear up all the data and recreate the table structure with specific columns on demand while developing your app. This article will show you how to do that and more.
When analyzing data, you may need to know the average salary of all employees, the quantity of goods in stock, the number of individual items in stock, the maximum or minimum cost, and so on. These tasks are easily handled with aggregate functions. Aggregate functions perform calculations using the values in a column in order to obtain a single resulting value.
Backendless supports several aggregate functions, such as:
- AVERAGE – to calculate the average
- COUNT – to calculate the number of rows in the query
- SUM – to calculate the sum of values
- MIN – to calculate the smallest value
- MAX – to calculate the largest value
Let’s take a closer look at how to work with aggregate functions using Backendless. In this article we will look at using aggregate functions with Backendless REST API, but we also show how to work with aggregate functions using Backendless SDK for iOS API, Backendless SDK for Android/Java API, Backendless SDK for .NET API, and Backendless SDK for JavaScript.
For this series, we are developing an iOS game called “TapMe”. As TapMe is a multiplayer game, it provides registration for the new users and login for the existing ones. In this article, we are going to demonstrate how to handle user registration and login, as well as how to store a player’s information in the database.
The source code for the game is available in the author’s personal Github repo: https://github.com/olgadanylova/TapMe.git
You can read Part 1 of this series here.
Some Backendless users choose to use REST APIs in their JavaScript projects. While many can simply use our pre-packaged JS-SDK, that SDK may not always be able to achieve the result the user is seeking. Today we’re going to show you how to build a custom and very light API client library for working with Backendless API. Some time ago, we created a simple NPM module named “backendless-request” for sending CRUD requests to the server. That package is used in all our services such as DevConsole, JSCodeRunner, JS-SDK, etc.. If you would like to see the sources of the package, you can find it on Github.
It is common for developers to build apps where users will have varying access to data and elements within the app based on the user’s role. Being able to limit user access is important to data security, user management, and often, the financial success of the application as user access is commonly tied to how much the user pays. In this article, we are going to show you how you can hide some object properties based on the user’s role. To accomplish this, we will be using Event Handlers.
An event handler is custom, server-side code that responds to an API event. For every API call, Backendless generates two types of events – “before” and “after”. The “before” event is fired before the default logic of the API implementation is executed and the “after” event is triggered right after the default API implementation logic. An event handler can respond to either one of these events. A synchronous (blocking) event handler participates in the API invocation chain and can modify the objects in the chain’s flow. For example, the “before” event handlers can modify arguments of the API calls, so the default logic gets the modified objects. Similarly, an “after” handler can modify the return value (or exception) so the client application that made the API request receives the modified value. For more about Event Handlers, you can read the documentation.
By the end of this guide, you will have a Backendless application with a custom API event handler that modifies objects received from a table and removes restricted properties based on the user’s role.
