I'm new to Salesforce. But I have quite experience with modern SPA frameworks (angular and mean stack). I'm experimenting a bit with Lightning framework (=aura components).

How does the authentication works? What are the real benefits of using Lightning Components against using other opensource framework (ex. angular with ngforce) from the point of view of authentication and data visibility (sharing rules, permission set)?


There has been a lot of discussion around speed of development and reusable components and while I do think we get decent marks for that the real promise of lightning components is that for the first time salesforce is opening up access to the presentation layer technology it is using to build customizable applications. The main benefits have not been realized yet externally but I do believe you are starting to see where things are going with lightning extensions, app builder, components from third parties being published on app exchange, etc. we are building an entire ecosystem, a shared ecosystem, where all parties are leveraging the same component-based architecture. The challenge right now is basically were asking you to pardon our dust because the real power lies in the integration of lightning components into various extension points and containers. For example I'm currently working on a "new" feature for lightning called Lightning Out (LO). I put new in quotes because this is merely the productization of an existing service and the underlying aura framework. In fact, for anyone doing Visualforce development over the past few years you've been unaware that one of the most exciting new standard components that salesforce has released in the past 3+ years, analytics:reportChart, is actually a lightning component exposed to Visualforce using the Aura Integration Service! LO Will provide the same capability for any lightning component to be used within VF. Even more exciting is the fact that along with integration into sales forces user experience technology LO also includes cross domain, external web container exposure support and oAuth authentication flows.

Another concept I want to highlight is that using LC does not mean you have to throw away your favorite framework (angular, react, polymer, etc.). We've been working very closely with angular for example to provide the toolkit that makes working with both angular (with ionic layered on top in my specific case) and LC productive and performant. For folks familiar with angular a concrete example of this interoperability comes in the form of a new angular directive, ltng-component, that makes it easy to use lightning components inside of an angular region including passing a litmus test of ng-repeat.

Both LO and LC/Angular support are still being developed but you should start to see these critical technologies in the wild soon.

In summary, LC is supposed to be in the component API, metadata, packaging business and not in competition with your favorite framework. With that said a big part of building a component-based ecosystem is having a reliable versioning system that allows a high level of confidence that in a pushed upgrade, multitenant, multi-author world that salesforce lives in anything that works today will continue to work release over release as push updates are applied. Most if not all existing third-party frameworks do not provide adequate versioning and version emulation support. At best they provide a no conflict mode. Salesforce is going after a much more rigorous world that includes shared libraries better versioned. As a concrete example what happens when you include angular multiple times in the same DOM even if it's the exact same version? now compound that by introducing multiple versions of angular in the same DOM. Finally, move the authors into separate organizations across space and time that are attempting to produce components that integrate in a specific customer as a composite solution. salesforce does not have the solution for this in place but were one of the few that are trying solve it and are positioned with an ecosystem in the enterprise business space ideally suited for this purpose.

  • Uao. Your answer is actually asnwering a lot more questions that there flying around in my mind. Thanks. – mcmc Apr 22 '15 at 15:50
  • LO sounds like a desperately needed feature in that it opens up a huge area of use cases that currently cannot be accessed by Lightning. Do you have a rough timetable for what release we might find that in? Not looking for a commitment, but this is a major roadblock I have been monitoring. – Adrian Larson Apr 22 '15 at 17:23
  • 1
    @AdrianLarson Safe Harbor and all that of course - LO is what I am currently working on personally with a target of GA in Winter '16 (at least in Visualforce as the container since that does not have the extra challenges of oAuth flow support). – Doug Chasman Apr 22 '15 at 20:12
  • @DougChasman Right, of course. Sounds like it is pretty far out on the roadmap. Are there other ways to surface Lightning Apps through the desktop UI that I remain ignorant of, or will LO be the first? I saw someone on SE here ask about making it work via Canvas Connected App but they haven't posted if it's a viable option. – Adrian Larson Apr 22 '15 at 20:17
  • Embedding a Lightning .app is totally possible using any iframe based approach including Canvas. This is embedding a single page app though which is a very course grained approach which might be fine if the interaction is also course grained. Lightning Out allows you to directly embed ltng components cross domain - they run directly in your DOM and automatically take care of cross domain (using CORS) communication, environment initialization, etc. This also means that your non-ltng container can directly communicate with the components and they can also wire up to non-lightning events etc. – Doug Chasman Apr 22 '15 at 20:36

There is no difference in terms of authentication. The real benefits of Lightning are short development times and reusable components, particularly for mobile apps. Sharing and permission sets aren't a part of Lightning and still need to be handled indepently through the normal means available within Salesforce.

  • I can beat again that (right now that Lightning App Builder is still in beta) development times are not faster at all than other opensource frameworks (just comparing documentation.. angular has much more tutorials and quickstart and example ready to use) but thanks anyway for the answer! – mcmc Apr 22 '15 at 13:20
  • Compared to existing SF pages, you don't for example have to write any controllers. If you go to the App Exchange, vendors already have components available to add features. There are numerous tutorials and Github repositories available already demonstrating how to develop with Lightning. For you it may be a matter of familiarity and comfort with your existing tools. I recommend the recent Lightning webinar series. – crmprogdev Apr 22 '15 at 13:30
  • Which we can find where? – Adrian Larson Apr 22 '15 at 17:17
  • They can all be accessed from the Salesforce1 Lightning Webinar Series page or on YouTube in the Salesforce Developer Channel. The Git repositories are referenced in the webinars. I don't have the links at hand although dcarroll has at least one. – crmprogdev Apr 22 '15 at 18:11
  • 2
    I would also recommend the the hands on Lightning Components Trailhead that was recently released developer.salesforce.com/trailhead/module/lightning_components – Doug Chasman Apr 22 '15 at 20:07

I think you can't create Lightning components with angular except you hack around ant put it in iframe based on this doc. https://developer.salesforce.com/page/Requirements_Checklist If you are thing of putting your stuff to app exchange better to go with aura

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.