September 24, 2015
Top 5 Things I Am Excited About After Dreamforce 2015

I spent the last full workweek at Dreamforce 2015 in central San Francisco. This was my first Dreamforce and while I was somewhat skeptical going in, after coming back I can say that it was not only an extraordinary experience, it also got me pretty stoked about many Salesforce features. These include some of the new features that they are releasing, as well as some older features that are either being upgraded, or were simply new to me.

These are the top five things that I am excited about after Dreamforce.


#5: Salesforce Streaming API

The Streaming API provides native realtime data support to Salesforce. For those who aren't familiar with realtime data, the basic idea is that it enables Salesforce to push data to your app when that data becomes available, instead of forcing your app to pull data from Salesforce when it wants it.

The obvious application of something like the Streaming API would be real-time dashboards, and this was in fact the sample use case in the presentation I watched. This presentation was called "Building Real-Time Dashboards with Salesforce Streaming API", and its slides, video and sample code will be posted here soon (along with all sorts of other cool content).

The Streaming API is not new functionality - but the Dreamforce session I saw on it was the first time I had seen it demonstrated, and I was impressed at how easy it was to set up. I plan on building a proof of concept of this API within the next months, so keep your eyes peeled for a post about that!

You can learn more about the Streaming API here or here.


#4: The Wealth of Salesforce IDEs

When I started developing with Salesforce, like many people I used the Developer Console. The many problems of developing solely in the Developer Console quickly became apparent, and my team recently switched to using Sublime Text with MavensMate. Shortly before Dreamforce my team purchased the IntelliJ IDEA in order to take advantage of the Illumniated Cloud plugin, although I had not made the switch before flying out (and still haven't, actually). My point is that, going into Dreamforce 2015, I did not think there were many good IDEs out there for Salesforce development. How wrong I was.

mm
Sublime Text with MavensMate plugin, my current Salesforce development environment.

It turns out there are many different IDEs for Salesforce. A few I learned about are:

  • Cloud9: Cloud9 is a multi-language IDE that has Salesforce support in beta. I spent some time at their booth and what I saw looked pretty impressive. The IDE is writtein in JavaScript and runs on Node.js, allowing it to run both in the browser and locally. Cool! It has a lot of other nifty features that you'd expect from a modern IDE, and some that you would not (like the ability to deploy directly to Heroku). I look forward to trying this one out.
  • Aside.io: this IDE only supports Force.com and is specialized to do so. Like Salesforce it runs in the cloud and claims to offer "uber fast" saves to Force.com servers. From the demo I saw it being used in this did appear to be the case. It also features an integrated test monitor. Also, completely free. I can see myself using this IDE during demos or in other situations where I either don't have access to my standard environment or want to demonstrate something without getting bogged down in the particulars of my development environment.
  • Welkin Suite: another Force.com-specific IDE, this one stuck out to me since it is Windows-only. As a Windows user at home and reluctant OSX user at work, this perked my ears up. The visual style clearly takes inspiration from Visual Studio, which is not a bad thing in my opinion, and it appears to offer many of the nifty features that VS offers (like the ability to easily navigate through code via keyword lookups, etc.)


Screenshot of the Visual-Studio inspired Welkin Suite

I still like Sublime Text, and interesting plugins are still being developed for it. Still, I definitely look forward to giving these IDEs a try.


#3: Heroku

Onc eagain, Heroku is not new - it's been around since 2007 and was acquired by Salesforce in 2010. I had some familiarity with it before going into Dreamforce, but not a whole lot; acquiring some more knowledge about it was one of my chief goals. I certainly was not disappointed.

My workplace builds a lot of integrations with Salesforce. Most of these are built by me. My own integrations usually end up hosted on a Drupal website, for a few reasons: first, Drupal is what I know (I was a Drupal development for years before moving onto the Salesforce team) and second, ASU is a Drupal campus - we know it, and trust it. So how do we talk to Salesforce? Through the Salesforce API - using either the Salesforce Suite module, or more recently, the Salesforce Query module of my own construction.

While this works, it isn't an ideal setup. Both Salesforce Suite and Salesforce Query constrain us in how we can transfer data into and out of Salesforce, and our integrations must be built around these constraints. Furthermore, while Drupal is a fine CMS, it contains far more than we need for a normal integration which needlessly slows us down. 

A Heroku-hosted app seems to me a much better fit for these sorts of integrations. Instead of dealing with a bloated PHP-based Drupal setup, Heroku allows us to write a lean, speedy app in Node.js (or in Python, or Go, or Scala...). We can then host the app offsite on Heroku's scalable servers. But the best part? Heroku Connect.

Heroku Connect synchronizes your Salesforce database with a Heroku Postgres database. Read from the Postgres DB, and you're reading from Salesforce. Write to the Postgres database, and the change is propegated to Salesforce within seconds. It's as close as you can get to direct access to the Salesforce DB, and it will allow us to write apps that are orders of magnatude more elegant.

I'll be rebuilding one of my integrations as a proof of concept on Heroku very soon, and I am really looking forward to seeing how much better I can make it.


#2: Lightning Components

Lightning was the hot word at Dreamforce 2015. The Salesforce Foundation seems to like the word so much that they've used it to describe the new UI experience overall, the Visualforce-esque view building system, the point-and-click app building tool, the design guide, and a conceptually unrelated data mapping tool. We also have Thunder now.

Of course, the part that most excites me is the Lightning Components feature.

While I'm mostly a backend developer, I've done some Visualforce in my time, and I've always felt locked in. You have to play by the Visualforce rules. Without custom theming, your app looks very Salesforce-y (arguably a good thing in some circumstances, but not so good in others). AJAX support is rather difficult and breaks in more extreme circumstances (I'll be writing a post specifically about this sometime in the future.) Basically, it's a walled garden.

Lightning doesn't feel that way to me. I think the primary reason for this is the fact that the controller language of Lightning is no longer Apex, it's JavaScript. Sure, Apex is still there, way in the back, but its functionality now is solely to give you data from the database. All controller-like behavior now lives in JavaScript, and it looks glorious.

Lightning is event driven and gives you plenty of options for setting up nifty event-based workflows. These events will primarily be used for communication between components within a Lightning application. This is because, unlike the page-based Visualforce, Lightning is application based - each application will consist of numerous components, which will result in far cleaner code and more maintainability (as well as reusability - any component you build can be encapsulated and used in other contexts).

It's a terribly exciting thing, and I'm racing the other developers on my team to be the first to build something with it. If you want to learn it for yourself, Salesforce's own Trailhead offers a Lightning Components section that should jumpstart you into the Lightning way of developing. 


#1: Salesforce + JavaScript

I was originally going to list Lightning Components as the thing I'm most excited about. But after some reflection, the thing that really gets me stoked is the fact that Salesforce is embracing JavaScript with a passion. Almost every entry on this list involves JavaScript being used to improve the Salesforce experience in some way. The Streaming API uses the CometD Javascript library. Heroku allows you to build JavaScript powered apps that integrate beautifully with Salesforce. Lightning Components is powered by JavaScript. And there's other things I haven't mentioned - like jsForce, a Node.js package that wraps the Salesforce API to enable the rapid construction of SF-integrated apps, or simply to manage your SF org from the command line.

I don't need to go over the reasons JavaScript is awesome for Salesforce - Adam Seligman did this well enough in his Developer Keynote, which is well worth a watch. But if you don't have time - Javascript is faster, and better for mobile. It is a language undergoing continuous development, with new libraries being built every day, all of which can be integrated into your Salesforce app. And in my opinion, it's more fun to write.

If you're a Salesforce developer and you don't know JavaScript, get on it.