Cloud Code allows you to extend the standard functionality of Nimbu with custom-tailered routes, callbacks, background jobs or back-end actions for your application.
Every Nimbu object in Cloud Code is exposed through our Nimbu JS SDK wrapper. This adds convenient wrappers around our JSON-API. For more information, see our Nimbu JS SDK documentation
With callbacks you can define custom code to be triggered before or after certain actions. These will fire regardless of the interface by which the item is changed: the website, the backend or the API.
Following “before” triggers are available:
channel.entries.createdchannel.entries.deletedchannel.entries.updatedcoupon.createdcoupon.deletedcoupon.updatedcustomer.createdcustomer.deletedcustomer.updateddevice.createddevice.deleteddevice.updatedproduct.createdproduct.deletedproduct.updatedFollowing “after” triggers are available:
channel.entries.createdchannel.entries.deletedchannel.entries.updatedcoupon.createdcoupon.deletedcoupon.updatedcustomer.createdcustomer.deletedcustomer.updateddevice.createddevice.deleteddevice.updatedorder.canceledorder.createdorder.fulfilledorder.paidorder.reopenedorder.updatedorder.attachments.expiredorder.attachments.readypage.createdpage.updatedpage.deletedproduct.createdproduct.deletedproduct.updatedThe syntax to define a callback is as follows:
Nimbu.Cloud.before("customer.updated", function(request,response) {
console.log("Object " + request.object.id + " will be updated");
});
For channels you can specify for which channel only the trigger should be fired:
Nimbu.Cloud.after("channel.entries.created", "foobar", function(request,response) {
console.log("Object " + request.object.id + " has been created");
});
The request object has following keys:
object: the Nimbu object for which the callback was triggereduser: the backend-useractor (or alias customer): the Nimbu actor (customer) who triggered the callbackchanges: when the object was changed, this object contains all keys which have been changed with the value [previous_value,new_value]In before callbacks, you can alter the information written to the database, i.e. to provide default values.
Nimbu.Cloud.before("customer.updated", function(request,response) {
request.object.set("foo","default value");
});
It is also possible to perform validations in a before callback and prevent invalid objects to be written to the database. For simple validations, it is always desired to configure these in the channel configuration, optionally using Conditionally Required fields. But complex validation logic can be accomplished using Cloud Code before callbacks:
Nimbu.Cloud.before("customer.updated", function(request,response) {
if(request.object.get("foo") != "some complex logic") {
response.error("A generic error message")
}
});
Nimbu.Cloud.before("customer.updated", function(request,response) {
if(request.object.get("foo") != "some complex logic") {
response.error("foo", "The value for foo is not valid")
}
});
Users are the team members as shown in the settings/account page in Nimbu. These are the people that can log into the backend directly and make fine-grained changes to the channel entries. They are associated with one or many sites. Actors (or customers) on the other hand are the entities that are listed in the Users collection in Nimbu. They live within one site and possibly have additional fields associated with them. In the callbacks either user or actor/customer is set. The user is set when the callback is triggered by a change in the Nimbu backend. The actor/customer is set when the callback is triggered by an API call.
When you can't decide between before and after callbacks, consider the following:
You can define custom urls on your websites where you can define more complex logic, redirects or rendering of certain templates.
The syntax is as follows:
Nimbu.Cloud.get("/foo/bar", function(request,response) { });
Nimbu.Cloud.post("/some/:variable/", function(request,response) { });
Nimbu.Cloud.put("/*path", function(request,response) { }); // path contains slashes
Nimbu.Cloud.patch("/object/:id", function(request,response) { });
Nimbu.Cloud.delete("/object/:id", function(request,response) { });
Nimbu.Cloud.route(verb, url, function(request,response) { });
// where verb is one of [GET, POST, PUT, PATCH, DELETE]
You can define custom Cloud Code functions which can be easily run from the Nimbu JS SDK or the API.
Nimbu.Cloud.define("my_function", function(request,response) { });
You can define custom background jobs functions which can be easily scheduled from the Nimbu JS SDK, the API or other cloud code. Background jobs can be used for long-running jobs (typically, something that does many API calls or runs for multiple seconds is desirable to put in a background job).
Nimbu.Cloud.job("my_job", function(request,response) { });
The request object has only one key:
params: this contains the params given when scheduling the background job.A background job can be scheduled as follows:
Nimbu.Cloud.schedule("my_job", data, timing);
// data contains all the parameters you want to pass to the background job
data = {
foo: "bar"
}
// timing can be one of following
timing = {
at: new Date(2018,12,10,15,3,10)
} // -> schedule at a very specific point in time
timing = {
in: "600s"
} // -> schedule at a certain duration from now. You can use 's', 'm' or 'h'
timing = {
every: "0 * * * *"
} // -> use crontab format to specify a recurring job
timing = {}
// -> schedule immediately
It is also possible to unschedule a job, as long as you use the exact data parameters for which the job was scheduled. You can also unschedule a specific job at a certain point in time
Nimbu.Cloud.unschedule("my_job", data);
Nimbu.Cloud.unschedule("my_job", data, { at: new Date(2018,12,10,15,3,10) });
It is possible to define custom buttons in the backend that trigger custom code on certain objects or collection of objects.
The syntax is as follows:
Nimbu.Cloud.extend(view, { name: "<label of button>" }, function(request, response) {})
Nimbu.Cloud.extend('channel.entries.show', optional-slug, { name: "<label of button>" }, function(request, response) {})
The view parameter is one of following possibilities:
channel.entries.listchannel.entries.showcollection.editcollection.listcoupon.editcoupon.listcustomer.listcustomer.showdashboard.listorder.listorder.showpage.editpage.listproduct.listproduct.showOnly for channel entry extensions a slug can be provided to limit the button to the given channel.
The request parameter has following attributes:
params: form parameters (currently not implemented yet)actor: information about the backend user performing the current action (name, email, role)object: object for which the action is being invoked => only applicable to show en edit actions, for channel.entries.list you will receive a representation of the channel on which the action is invokedOn response, following methods are possible
success(message): actie geslaagd, message wordt in succes notification wordt getoond in backenderror(message): actie niet ok, er wordt message in rood getoondredirect_to(url_or_path, options): redirect naar url or pad, options is hash met success of error als key en dan de message die gebruikt wordt als flash na de redirectWhen a breaking change is needed in the Cloud Code engine, we'll introduce a new version based on the date this version was introduced. Following versions are in use:
2011-08-03: Initial Cloud Code Version.2020-06-08: Allow cloud functions to return non-200 http status codes.2021-01-12: Add the header Content-Type: application/json for routes returning JSON data.2022-02-08: Update moment.js to version 2.29.1