Salesforce Lightning – a Primer

Since the beginning of the 21st century, Salesforce has grown from relatively humble origins in the then nascent Software-as-a-Service (SaaS) industry to becoming the dominant CRM platform in 2016. Along the way Salesforce has broadened its reach to cover many different aspects of contemporary enterprise cloud computing: sales, service, marketing, analytics, community, social and mobile apps, amongst others.While the primary enterprise offerings from Salesforce continue to be the various Clouds (Sales, Service, Marketing, etc.), in the last decade or so a thriving developer community has built up around Salesforce’s Force.com Platform-as-a-Service (PaaS) suite of development tools. Force.com allows developers to build upon the out-of-the-box flavours of Salesforce.com, to extend functionality where necessary, and to build standalone apps running on Salesforce’s underlying multitenant architecture.

In this post I provide a potted history of development on the Force.com platform to set the context for the latest innovation, Lightning. While configuration (clicks not code) of the platform remains a huge part of the process, I will concentrate on how Force.com can be used to extend Salesforce programmatically. I will then turn to the latest addition to the Force.com family – Lightning – and explore how it represents a major shift for Force.com and the broader Salesforce suite.

This post is aimed mainly at Salesforce experts and developers; however it will be useful to a wider audience, such as web and app designers/developers, UX experts, and managers evaluating different PaaS development offerings.

A Short History of Force.com Development

A decade ago the only real way to programmatically extend Salesforce was to make use of S-Controls. These were packages of JavaScript and HTML that could be inserted into Salesforce to extend functionality – however there were limitations. They were essentially standalone web pages, embedded in an iFrame, and could only interact with Salesforce via API calls using Javascript. There was no data binding, no access to built-in platform behaviour, no respect of the metadata – validation had to be specifically coded into the S-Control. The presentation of data had to be coded too – Salesforce stylesheets could be used, but had to be manually brought into the HTML code, and there were no standard components to facilitate laying out a page to match the look and feel of standard Salesforce.

All this changed in 2008 when Force.com was introduced, with Apex and Visualforce. Apex is a fully featured programming language, running server-side, which allows developers to directly access and control Salesforce’s data model and functions; it is based on Java, and so will be familiar to any Java developer. Visualforce is a component based user interface framework, including a tag based mark-up language similar to HTML. Together they can be combined using the traditional model-view-controller (MVC) design pattern, providing developers the ability to build custom pages and apps strongly integrated with Salesforce.

Apex and Visualforce have dominated Salesforce coding ever since; they provide a powerful yet easy-to-use means to extend the platform. In the last few years, however, there have been shifts in the wider world of web development. Increases in both software and hardware performance, and changes in the needs of users, have led to a move away from traditional page-centric, server-side scripting, towards a greater emphasis on client-side scripting. This is has been partly driven by the rise of mobile technology, which has also required improvements to the UI, specifically in the areas of responsive design and data input (fingers, not keys), and reductions in calls to the server due to limited network bandwidth.

A whole ecosystem of client-side scripting and user interface frameworks have sprung up (jQuery, AngularJS, Bootstrap, etc.) to accommodate these shifts in the way people use web technology. Of course, Salesforce developers were keen to get in on the action!

Salesforce responded by introducing various client-side options to Visualforce. It became possible to use JavaScript in combination with the Salesforce REST API to build entire apps within a page, where Visualforce was really just acting as a container for this new breed of Single Page Applications (SPAs). Then JavaScript Remoting for Apex was introduced, allowing developers to call server-side Apex methods from JavaScript. This ability to make event driven, asynchronous calls to the server, rather than rely on page refreshes, literally revolutionized Force.com development. Suddenly it was possible to create the kind of fluid, responsive apps that have dominated web development in the last few years, especially on the mobile platform.

Salesforce were certainly not unaware of these changes in the mobile world. In 2013 they introduced the Salesforce1 mobile app. Although there had been previous incarnations of a mobile app for Salesforce (Salesforce Classic and Salesforce Touch), this was the first time most of the Salesforce functionalities were available on a mobile device. And it’s also where Lightning enters our story…

Salesforce realised that they needed to build a mobile-optimised UI for Salesforce1. To do this they developed a scalable, component-based user interface framework that allowed the reuse of discrete UI components across different pages. The framework bridged client-side and server-side scripting to provide fast responsiveness combined with more complex business logic, again driven in part by the need to limit calls to the server on mobile devices due to network bandwidth limits. The framework also had the responsive design elements necessary for mobile built in from the foundations. This became the Lightning framework, upon which the Salesforce1 app was built.

(In fact the Lightning framework is based on the Aura framework, which started as an internal initiative within Salesforce, and has subsequently been made open-source.)

A year after Salesforce1 was launched Salesforce opened up the Lightning framework to developers, allowing them to create their own components (Lightning Components), and to modify and extend Salesforce’s own components. This, along with the Lightning App Builder, could be used to quickly and easily create new apps for Salesforce1.

The next logical step was the unification of mobile and desktop across the Salesforce platform, using Lightning. At this point, Salesforce desktop users were still using the same user interface introduced in 2010, which by now was starting to look a little long in the tooth. Developers have always been somewhat frustrated by the restrictions placed on modifying standard page layouts in Salesforce, having to resort to Visualforce more often than not to fulfil their requirements. While technically possible to use Lightning Components within Visualforce, or to create standalone Lightning apps for the desktop, there was not an easy way to integrate Lightning Components directly into the old UI.

Finally, in 2015, Salesforce announced the Lightning Experience. This was the biggest change to the desktop user interface in years, bringing the new component based UI from Salesforce1 to all devices. Developers could now develop Lightning Components and Apps and integrate them directly into Salesforce.

The Salesforce Lightning Family

Now that the background has been covered, I want to expand a bit on each of the different parts of Salesforce Lightning – as a marketing phrase it is used extensively and sometimes confusingly! What follows is a breakdown of each Lightning element:

Lightning Component Framework

A scalable, component-based UI framework for developing web apps for mobile and desktop devices, specifically single-page applications. Based on the open source Aura Framework, it includes an out-of-the-box set of components, event-driven architecture and is optimized for performance. Client-side code is JavaScript, server-side code is Apex.

Salesforce1 and Lightning Experience are both built upon this framework.

Lightning Components

These are self-contained and reusable units of an app. They represent a reusable section of the UI, and can range from a single line of text to an entire app. The framework comes with a set of prebuilt components, such as components for inputting data (inputfield, inputdate, etc), which can be combined and configured into new reusable components. You can also add other components such as HTML, CSS, JavaScript to enhance the component’s function and build sophisticated UIs. Components can be configured by setting values of attributes, exposed in their definition. They interact with their environment by listening to or publishing events.

Lightning Components can be configured to appear in Lightning Experience, via the App Launcher or as components in standard page layouts (although this is only available in beta at the moment), and Salesforce1, via the Navigation menu or in Lightning Pages. They can also be used in Lightning Community pages.

Lightning Applications

A Lightning Application is a special kind of top level Lightning Component, which provides a standalone entry point for the app and enables you to define the overall application layout, style sheets, and global JavaScript includes. The resource bundle has an .app extension, rather than the normal .cmp extension for standard Lightning Components. Other Lightning Components can then be added into the Application as required.

The difference between Lightning Applications and Components is that you can only access Applications from the browser URL – they are intended to be standalone apps, rather than components used within the Salesforce1 app or Lightning Experience. It is not possible to access a Lightning Component directly from the URL, however, it must be wrapped in an Application.

You can access a Lightning Application using the URL:

https://.lightning.force.com//.app

where <myDomain> is the name of your custom Salesforce domain.

Lightning Experience is itself a Lightning Application, with the URL:

https://.lightning.force.com/one/one.app

Lightning Events

Event-driven programming is used in many languages and frameworks, including JavaScript. Lightning Components will listen for events to occur (typically users interacting with the user interface), which in turn trigger code to perform certain actions.

Lightning Pages

A custom page layout, built in the App Builder for Salesforce1 by drag and dropping Lightning Components on to the page. It is not possible to see these pages in Lightning Experience at the moment.

Lightning App Builder

A point-and-click tool that can be used to create custom mobile app pages for Salesforce1. It is also possible to modify standard page layouts in Lightning Experience in the same manner, although this is in beta at the moment. The idea behind the App Builder is to allow non developers to create their own pages by dragging and dropping pre-configured components (standard or custom) onto the page. The Lightning Framework will handle responsive design across different sized devices – the user just needs to select from a list of different page layout templates.

Lightning Experience

The introduction of Lightning Experience has finally created a unified UI experience across all devices. This is the new user interface for Salesforce on the desktop, built with the Lightning framework, in the same way that Salesforce1 was built.   The look and feel is modern; it has responsive design built into the UI and the page is updated dynamically via JavaScript rather than by whole page refreshes, leading to a more "app-like" experience. Lightning Experience replaces the previous five year old UI, now called "Salesforce Classic".

It will be possible to add Lightning Components directly into standard page layouts, using the App Builder (this is in beta at the moment). Custom Lightning Components and Applications can be accessed via the App Launcher page.

Visualforce is still supported, and will continue to be; however there are some minor changes to how it works (the main one being that Visualforce pages now run in an iFrame within the Lightning Experience app, so page navigation needs to be modified).

Lightning Community Builder and Templates

Similar to the Lightning App Builder, this provides the means to build Salesforce Communities with Lightning Components. Based on a number of templates designed for different types of community, the developer can add and modify functionality easily, by dragging and dropping new components on to the page.

Lightning Design System

A CSS framework designed for use in both Visualforce and Lightning Components. It provides a means to produce custom pages, components and apps that match the look and feel of the standard Salesforce1 and Lightning Experience UIs. It provides a responsive grid layout system, and has accessibility baked in.

It is comparable to other frameworks, such as Bootstrap or Foundation, but is specifically tailored to comply with the Salesforce design principles.

Lightning Connect

Originally branded as External Data Objects, this functionality allows external data sources to be defined and interacted with in Salesforce as if they were standard Salesforce SObjects. It uses the OData protocol to connect to the external data sources.

Lightning Schema Builder

A rebrand of the existing Schema Builder, used to visually configure and manage the underlying Salesforce data model.

Lightning Process Builder

Another rebrand, this time of Visual Workflow, the graphical workflow tool that can be used to automate business processes. It replaces some aspects of traditional workflow rules and Apex triggers.

Lightning Exchange

This is the section of Salesforce AppExchange dedicated to Lightning Components. Third party developers provide custom Lightning Components dedicated to specific industries or areas of functionality.

Implications of Lightning

It is inevitable that, with Lightning, Salesforce developers are going to have to learn to code differently than they do at the moment (client-side centric with reusable components, rather than page-centric on the server), and also to understand web design to a greater extent.

Lightning is a new technology and, in my experience, is still in its infancy in the development community. It is a little too early to say how it is likely to affect timescales for delivery, but there will likely be an impact during adoption so we will see a slowdown initially, while everyone gets used to the new approach.  This is a good reason for people to start using Lightning as soon as possible!

Moving forward, I don’t foresee much more coding than we might have seen traditionally with Apex and Visualforce.  We still can use configuration in the same way as before, and Apex is still working in the back end.  It’s mainly the UI that has changed, and primarily the introduction of client side scripting and API calls to get data, rather than server calls and page refreshes.  Most developers will be familiar with JavaScript, but may have only used it so far for validation, popping up alerts, and so on, rather than API calls.  The other new part that may be unfamiliar to some developers is the need to work more closely with HTML/CSS styling than they are used to with Visualforce.

Finally, with Lightning, there is a much greater emphasis on building reusable modules of functionality. Developers would benefit from creating a library of reusable Lightning Components that could be deployed across projects, as this would speed up subsequent development effort and allow a consistent approach to be followed.

Addendum

Training Resources

Lightning is a powerful addition to the Force.com toolkit, however it is also a new technology and many Salesforce developers used to Visualforce and Apex may find they struggle at first to migrate over. This is the direction that Salesforce is going with Force.com development so it is important that developers become accustomed to it.

Thankfully there are many resources available online to help the process.

Salesforce provide certification in various areas and at various levels of proficiency.

http://certification.salesforce.com/

Further help can be found within the Salesforce Developers community

https://developer.salesforce.com/

Finally, I can’t recommend enough the excellent Salesforce Trailhead. This site provides free tutorials in all aspects of Salesforce, including Lightning. It uses gamification to help make learning more fun, and allows developers to attempt challenges (and be assessed on the results) within their own developer orgs.

https://developer.salesforce.com/trailhead/en