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:
- As Visualforce pages are essentially dynamically rendered HTML pages output by Salesforce servers, these can also be used to build public-facing websites and also pages that adapt to various devices such as mobile phones and tablets (given the appropriate coding by the developer). The Salesforce Streaming API is currently only accessible via JavaScript.
- Websites built using traditional off-platform languages, such as .NET, Java, Ruby, or PHP, are required to access Salesforce via the REST/SOAP and Streaming API's only.
- A client is built using a device-specific platform and UI technology, such as a native mobile application using Xcode, Java, or a natively wrapped HTML5 application.
- The AJAX Toolkit is a JavaScript library used to access the Salesforce SOAP API from a Visualforce or HTML page. It is the oldest way in which you can access Salesforce objects and also Apex Web Services from JavaScript. Though it is possible to utilize it from Custom Buttons and Visualforce pages, my recommendation is to utilize one of the more recent Visualforce communication options (by associating Visualforce pages to your Custom Buttons rather than JavaScript). Salesforce only supports the very latest version of this library, which is also quite telling in terms of their commitment to it.
- Lightning utilizes the
Content-Security-PolicyHTTP 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. - Lightning Out is a technology that allows Lightning Components to be hosted on external websites. Components running within Lightning Out are still able to use Lightning Server Side and Lightning Data Services to communicate with the backend. Note that Lightning Data Services at time of writing were only in Developer Preview.
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.
Tip
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.
Note
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.