Activity Forums Salesforce® Discussions What is the difference between Queueable apex and future method in salesforce?

  • Nikita

    Member
    September 6, 2019 at 6:30 am

    Hi Laveena,

    The main differences between @future methods and Queueable Apex jobs are:

    • When you enqueue a new job, you get a job ID that you can actually monitor, like batch jobs or scheduled jobs!
    • You can enqueue a queueable job inside a queueable job (no more “Future method cannot be called from a future or batch method” exceptions). As for Winter ’15 release, you can chain a maximum of two queueable jobs per call (so a job can fire another job and that’s it!). With Spring ’15 release, this limit has been removed.
    • You can have complex Objects (such as SObjects or Apex Objects) in the job context (@future only supports primitive data types)
  • Achintya

    Member
    September 6, 2019 at 11:23 am

    Batchable calls were designed to allow for heavy asynchronous processing. But, it was the only asynchronous code at one point, and it was too "heavy" in terms of resource usage and had a lot of baggage associated with it. It required a long time to process and was often used only to handle callouts or things that were slightly longer than a normal transaction could handle.

    So, next came future methods. Unlike Batchable methods, they were lighter on resources and perfect for doing that job that Batchable was doing before, but much more efficiently. Unfortunately, it was too efficient. You didn't know when the job was done (no Job ID), and it only had a limited amount of space to store data (the reason why it only accepted primitives and collections thereof).

    In response to feedback, a third version of the asynchronous code was designed: Queueable. It was lighter than Batchable, but it gave you a Job ID and let you store complex data patterns. The lesser resources it used compared to batchable also meant higher limits. Queueable was meant to be a hybrid between the limited future methods and the resource-hungry Batchable interface.

    So, to get back to your question: you should always avoid passing in the entire SObjects, especially if they may change between serialization and execution. If you need heavy processing, you probably want Batchable, while if you want normal-sized transactions with increased limits, you probably want Queueable. Of course, you can still use future methods if you don't need to monitor the results of the execution, and they'll continue to work for the foreseeable future.

Log In to reply.

Popular Salesforce Blogs

Popular Salesforce Videos