Fundamentally, any communication between the user's chosen device (client) and the data and logic available on the Salesforce server occurs using the HTTP protocol. As a Force.com developer, you rarely get involved with the low-level aspects of forming the correct HTTP POST
or HTTP GET
request to the server and parsing the responses.
For example, the Visualforce apex:commandButton
and apex:actionFunction
(AJAX) components do an excellent job of handling this for you, resulting in your Apex code being called with very little effort on your behalf apart from simply using these components. Salesforce also takes care of the security aspects for you, ensuring that the user is logged in, and has a valid session to make the request to the server. For Lightning Components, there are no direct equivalent components through the component markup. Instead, the $A.enqueueAction
JavaScript method can be called from a component's client-side controller method to access the Apex code.
Depending on the context your client code is running in, Force.com offers a number of communication options to either perform CRUD operations on Standard or Custom Objects, and/or invoke your application's Apex code to perform more complex tasks.
It is important that you correctly place the logic in your Domain and Service layers to make sure that, regardless of the client communication options, the backend of your application behaves consistently and that each client has the same level of functionality available to it. The sections in this chapter will show how to ensure that, regardless of the communications approach utilized, these layers can be effectively reused and accessed consistently.
Although the upcoming sections discuss the various communications in further detail, a full walk-through of them is outside the scope of this book. The Salesforce documentation and developer site offer quite an extensive set of examples on their use.
The aim of this chapter is to understand the architecture decisions behind using them, related limits, and how each interacts with the Apex code layers introduced in the previous chapters.
This table lists the various client communication options available along with the types of user interface they are typically utilized by. It also indicates whether the API calls are governed (see the following subsection on what this means).
Communication option |
Visualforce Pages (1) |
Lightning Component |
Custom Button or Link |
Web-sites |
Native device UI (3) |
API limits |
---|---|---|---|---|---|---|
Visualforce Components ( |
Yes |
No |
No |
Yes (1) |
No |
No |
Visualforce JavaScript Remoting (Apex code) |
Yes |
No |
No |
Yes (1) |
No |
No |
Visualforce JavaScript Remote Objects (CRUD operations) |
Yes |
No |
No |
Yes (1) |
No |
No |
Salesforce REST/SOAP API's(CRUD API, Apex SOAP and REST API's, Analytics) |
Yes |
No (5) |
No |
Yes (2) |
Yes |
Yes |
Salesforce Streaming API (Read access to standard and custom objects) |
Yes |
No (5) |
No |
Yes (2) |
Yes |
Yes |
AJAX Toolkit (4) |
Yes |
No |
Yes |
Yes (2) |
No |
Yes |
Lightning Server Side Action |
No |
Yes |
No |
No (6) |
No |
No |
Lightning Data Services (CRUD access) |
No |
Yes |
No |
No (6) |
No |
No |
The following notes apply to the preceding table:
Content-Security-Policy
HTTP header as recommended by W3C. This controls how (use of HTTPS) and from where (Lightning domain only) resources are loaded from the server. Since the Salesforce API's are served from a different domain, they cannot be called directly from JavaScript code inside a Lightning Component. Instead, you must call such API's server-side from the component's Apex controller.As shown in the preceding table, for some communication methods, Salesforce currently caps the amount of API requests that can be made in a rolling 24-hour period (though this can be extended through Salesforce support). This can be seen on the Company Information page under Setup and the API Requests, Last 24 Hours and Streaming API Events, Last 24 Hours fields.
Note that these are not scoped by your application's namespace unlike other governors (such as the SOQL and DML ones). As such, other client applications accessing the subscriber org can consume, and thus compete with, your application for this resource. If possible, utilize a communication approach listed in the preceding table that does not consume the API limits. If you cannot avoid this, ensure that you are monitoring how many requests your client is making and where aggregating them using relationship queries and/or Apex calls is possible.
If you are planning on targeting Professional Edition, be sure to discuss your API usage with your Partner Account Manager. The accessibility within this edition of Salesforce when using API's such as the Salesforce SOAP/REST API, Streaming API, and AJAX Toolkit is different from other editions. For the latest information, you can also review the API Access in Group and Professional Editions section in the ISVforce Guide, available at https://na1.salesforce.com/help/pdfs/en/salesforce_packaging_guide.pdf.
As discussed in Chapter 4, Apex Execution and Separation of Concerns, the transaction context spans the execution context for a request made to the Salesforce server from a client. When writing the client code in JavaScript, be careful when using the CRUD-based communication options such as Visualforce JavaScript Remote Objects, Lightning Data Service and Salesforce API, as the execution scope in the client does not translate to a single execution scope on the server.
Each CRUD operation that the client makes is made in its own execution scope and, thus, its own transaction. This means that, if your client code hits an error midway through a user interaction, prior changes to the database are not rolled back. To wrap several CRUD operations in a single database transaction, implement the logic in Apex and call it through one of the previous means, such as Visualforce JavaScript Remote Actions or a Lightning Server Side Action. Note that this is generally a good practice anyway from a service-orientated application design perspective.
The manifest
attribute on the Visualforce apex:page
element is part of the HTML5 standard to support offline web pages. While a full discussion on its use is outside the scope of this book, one thing to keep in mind is that any information you store in the browser's local offline storage is not secure. This attribute requires the use of the docType
attribute to indicate that the page output is HTML5-compliant.
Salesforce, however, introduced this feature mainly to support hybrid mobile applications, wanting to utilize Visualforce pages within a native mobile application container that supports the offline mode. It is not supported in any other context. In this case, the offline content is stored within the mobile application's own private store.
Hybrid mobile applications in the context of Salesforce Mobile SDK's are those that use a small native to the mobile device application that hosts a mobile browser that then utilizes the Salesforces login and Visualforce pages to deliver the application. In general, this would require a network connection; however, with the help of the manifest attribute, offline support can be achieved.
Lightning Components cannot control this attribute currently, since they do not own the page. It is the responsibility of the Salesforce1 and Salesforce LEX standard UIs to implement this attribute. Salesforce1 Mobile does support some offline capabilities in terms of record editing; however, there is no support currently for Visualforce or Lightning-based custom UIs.
3.16.81.33