A Solution Architect’s Take on Lightning

Russell O'Brien

is a Salesforce Solution Architect with a depth of experience in the Computing industry from mainframe and client server to cloud and mobile. He has operated his own Integration Consultancy and has also had extensive involvement in Quality Assurance including Agile Testing. Russell currently lives in Australia and has 13 Salesforce certifications.

Lightning Component Interview
with Russell O’Brien 


In recent times much has been published about Salesforce “Lightning” technology. It’s viewed by many as a pathway to the future. But what is Lightning and why is it so popular? To find out Focus on Force have interviewed Russell O’Brien who works as a Salesforce Solution Architect and is a strong advocate of Lightning.

Firstly, what’s your experience of Salesforce? How long have you been using it?

I first came across Salesforce in 2005/6 when I was setting up an integration consultancy. These were early days of course but the possibilities were obvious and I was interested, in particular, with the underlying platform and how it could integrate with applications hosted elsewhere. I did a lot of “tinkering” back then. My commercial development experience with Salesforce began around 2012. Since then it’s been a solid mix of Sales / Service cloud implementation plus custom stuff using Apex, Visualforce, Visual Flow and, more recently, Lightning.

Would you mind describing “Lightning” for me … in layman’s terms?

Without going into the history, I think it’s worth beginning by saying that “Lightning” isn’t a single technology and also that these “technologies” aren’t really related. This has caused plenty of confusion. Let me explain...

There are 3 core “offerings / products” Salesforce have that come under the “Lightning” banner. These are:


  1. Lightning Experience
  2. Lightning Connect
  3. Lightning Components


They are NOT technically related. A Salesforce purist may disagree, but for the purpose of understanding Lightning it will help to think of them as being separate.


Lightning Experience is Salesforce’s response to the need to update its User Interface and User experience on the desktop … to bring the Salesforce Interface up to current Internet / web standards and customer expectations. I’ll oversimplify here by saying that all the user needs to do is flick a switch and their experience of Salesforce changes from the one that’s been with us from day 1, to the icon-style experience you see on modern sites nowadays. Lightning Experience was unveiled by salesforce with much fanfare in late 2015.

So, Lightning Experience is just a change to the Salesforce user interface on the desktop?

Yes. You can switch between the traditional and new interface, but that’s what it is … bringing Salesforce into the modern world.

And Lightning Connect?

Lightning Connect is an Integration Technology.


It allows the use of external data, from other systems’ data stores, in the classic Salesforce way i.e. as objects and relationships between objects within Salesforce. The external data becomes available to Salesforce developers, as if it were resident within Salesforce itself. They can view the data and update it just like other Salesforce records, even though that data exists outside Salesforce.


For me Lightning Connect is a holy grail. Prior to it integration was achieved either by using ETL tools to load external data into Salesforce OR by building integration between Salesforce and external systems.


Lightning Connect doesn’t cover all the bases, so the two older ways still have their place, but it’s clearly a pathway to simpler solutions where data sharing across applications is necessary.

And Lightning Components ?

Ah yes. Lightning Components!


To put this in context it’s important to understand recent technology and user changes, in particular mobile. Mobile is all pervasive nowadays. There are thousands upon thousands of apps you can download to mobile devices and Salesforce is determined to be a part of the mobile world … hence their Salesforce1 mobile platform.


At the same time there’s been a huge growth in JavaScript development. The JavaScript frameworks now available are extremely powerful and for applications that rely on sexy user interfaces use of these is pretty much a necessity. That’s why JavaScript is becoming an ever more important item to include in a techy’s CV.


Non-Lightning Salesforce applications CAN make use of these frameworks. However the use of Apex, and in particular Visualforce pages, both of which are Salesforce propriety technologies, is server centric. They therefore bring into play potential connection and performance issues. These CAN be dealt with, but the solutions are sometimes complex and quite often development hungry.


Enter “Lightning Components”. “Lightning Components” are a client-centric solution for building Salesforce apps. When you want to create a new application, you create (or reuse existing) components and include them in your App. These components use HTML, CSS and JavaScript to provide the business functionality that’s needed. The execution of these activities takes place on the device. You don’t need a connection to the internet. Interestingly Salesforce uses similar terminology to that used for their Visualforce technology i.e. Lightning Components use “Controllers”, just like Visualforce … only, for the most part these are client-side JavaScript Controllers as opposed to server-side Apex Controllers.


This doesn’t mean you won’t occasionally still need to use Apex. Information about your customers for example is still held in the Salesforce database, i.e. on the server, and you’ll typically use Apex to retrieve it, and bring it down to the device. In this case you’d use a JavaScript “helper” to make a callout to an Apex Class to get the data and pass it back.


Lightning Components also use a nicely “decoupled” event model to trigger activities on the device. This covers things like user actions e.g. user clicking the “Save” button, and also programmed events, that are triggered based on logic coded in JavaScript. The decoupled nature of these events, means that nothing breaks if, for example, there’s a missed response. Also, when there’s a need to execute activities on the server, it’s done in bulk. In other words many actions are accomplished “together”, not one at a time. Salesforce developers who have struggled with salesforce Governor limits will really appreciate this one.

Sounds impressive. So this is why I’ve been seeing JavaScript as “highly regarded” in Job Specs for Salesforce of late?

That’s right. In particular organisations that are building mobile apps will be looking for JavaScript skills, because there’s so much of it in Lightning Components.

What about HTML and CSS?

Yes, definitely very useful as well. When you create a Lightning Component, it’s actually a “bundle” of things. The bundle consists of a component piece(s), which is HTML-ish, Controller and Helper pieces which are JavaScript, and a style piece which is CSS. So, you see the trio – HTML / CSS / JavaScript. There are other things you can include in the bundle, but these three are the essence of it.

What’s available within Salesforce to help create Lightning Components?

A couple of things come to mind. Salesforce has a “Lightning Component Framework” that developers can use to create component-based apps for mobile and desktop devices. It allows multi-tier component development using JavaScript on the client and Apex on the server.


There’s also a Lightning Design System that makes it easy to build applications from a UI perspective. It’s Salesforce’s answer to the likes of Twitter Bootstrap and contains a CSS Framework, Icons, Fonts etc.

That explains the technology, but what about rolling Lightning Components out? If you work for an organization that wants to get into Lightning Components, how would they do it?

The simple answer is really, more or less, the same as when trying to rollout a “building block” approach to development. The use of a “component” style approach isn’t new. Salesforce already have it in the form of Visualforce Components … for server-sided development.


The areas you should look to cover off include:

  • 1
    Develop (or reuse existing) Lightning App training to educate developers and provide effective dev support.
  • 2
    Create and socialise a Lighting Development Methodology. Includes standards + best practice re Naming Conventions, Accessibility, UI standards, Events, JavaScript, Apex.
  • 3
    Create a specialised component register and search facility to facilitate use of existing components.
  • 4
    Create a Lightning Component Test Methodology and enforce adherence to standards therein.
  • 5
    Define and implement a BETA Test program to ensure optimal customer experience through effective user feedback.
  • 6
    Define a process for establishing commercially viable custom components on the App Exchange.
  • 7
    Assign “Champions” for the various technical and business genres. Champions act as touch points to assist with component utilisation.
  • 8
    Maintain a simple, clear register of licensing / cost data for each utilised App Exchange component.
  • 9
    Provide Mobile “Orientation” training for experienced Salesforce developers.
  • 10
    Include an approach / best practices for component breakdown and assembly in the Development Methodology.
  • 11
    Include UI standards in the Development Methodology. Engage specialist UX providers to advise on UX best practice.
  • 12
    Document and socialise a Visualforce to Lightning Component Migration approach. This can be included in the development methodology.

So, there’s quite a lot to it and much of it is about sharing and reusing. How often have you re-invented the wheel because you didn’t know it already existed...

Are there any things NOT covered by Lightning Components … that Salesforce still need to do or complete?

Until recently I was troubled by the absence of Visual Flow in the mix. I use flows a lot for “in screen” dialogs … conversations or wizards you may know these as. They’re very useful and easy to develop and adapt. They truly transform the user experience.


As of March 2018 “Lightning Flow” has been included as part of the Lightning offering. It’s still undergoing development with things like Flow Stages and a Flow Debugger on the Roadmap. Salesforce are really stepping up here. We can expect to begin seeing Flow Components on the AppExchange in the near future.

How would you suggest going about learning Lightning Components?


There’s an online Salesforce course called “Creating Lightning Components” that’s a bit over an hour long. It provides an excellent introduction and covers everything from component markup and style, component nesting, binding with Apex and also the event handling model. It comes with an app building exercise so you get some useful hands-on as well. There’s also an excellent trailhead covering the Lightning Design System. I’d recommend completing that, as well as all of the other Lightning trailheads of course.

Beyond that I suggest downloading the Lightning Components Developers Guide. There’s loads of detail especially around styling and JavaScript.