4

It looks like Salesforce Functions will be in beta soon (apparently they will be available sometime after Spring 21... and we just got that).

What will be the killer app / use case that will really sell this functionality to my clients?

How do Functions compare to Heroku for example in cost/ease of use? Will they be able to do things Heroku cannot?

Will Functions be better than just including a static resource? Will they be invokable from more contexts?

Are there other things I should consider - response time, resource use when thinking about implementing them?

Functions docs here

1 Answer 1

10

I'd recommend looking through the functions documentation as it's in beta and things may change. A lot of what's said below is taken from those docs. Hopefully, as more users use the beta - you may get other answers/feedback on this.

What will be the killer app / use case that will really sell this functionality to my clients?

There's a Why Salesforce Functions section. Some points it makes

  1. Gives you the flexibility to use the languages and tools of your choice.
  2. Opens up the possibility to use open-source or 3rd party frameworks in those languages (saving you time)
  3. It's part of the Salesforce infrastructure - which means you can integrate securely (and easily!) with your org as well as be in a Salesforce managed elastic compute infrastructure.
  4. You can now perform compute-heavy tasks that may have been difficult or impossible to do before.

There's a functions-recipes repo that's to showcase how to do things (rather than what cool things you could do), but probably important to point out the first example is Process large data

There's also a Solutions, Samples, and Tools page that may give you a better idea.

How do Functions compare to Heroku for example in cost/ease of use? Will they be able to do things Heroku cannot?

I think the key difference with functions vs. Heroku is, again, the fact that Functions apply more natively to the Salesforce platform and allow you to focus less on server support. That's a big win. I don't have information on pricing, but since it only runs when called - it may end up being a cost saving depending on a customer's use case and what the pricing ends up looking like.

Back to the "native to Salesforce platform" point, the Salesforce SDK will allow you to have visibility to the platform with no need to manage authentication. You can see an example of how that looks (code snippet below)

// Insert the record using the SalesforceSDK DataApi and get the new Record Id from the result
    DataApi dataApi = context.getOrg().get().getDataApi();

    String timeStamp = new SimpleDateFormat("yyyy.MM.dd.HH.mm.ss").format(new Date());
    String accountNameWithTimestamp = String.format("%s-%s", accountName, timeStamp);

    Record account =
        dataApi
            .newRecordBuilder("Account")
            .withField("Name", accountNameWithTimestamp)
            .withField("AccountNumber", accountNumber)
            .withField("Industry", industry)
            .withField("Type", type)
            .withField("Website", website)
            .build();

    RecordModificationResult createResult = dataApi.create(account);

    // Query Accounts using the SalesforceSDK DataApi to verify that our new Account was created.
    String queryString =
        String.format("SELECT Id, Name FROM Account WHERE Id = '%s'", createResult.getId());
    List<Record> records = dataApi.query(queryString).getRecords();

Will Functions be better than just including a static resource? Will they be invokable from more contexts?

Can invoke functions from anywhere you can use Apex code:

  1. Apex actions in flow
  2. Batch Jobs
  3. Apex Triggers
  4. Apex Platform Event Subscriptions

Are there other things I should consider - response time, resource use when thinking about implementing them?

There are identified limits.

  1. 2 minute timeout for response from synchronously invoked Function
  2. No limit for number of async Function invocations from apex
  3. 15 minute limit for execution time within the compute environment
  4. 1 GB process memory
  5. Payload size limit: 6 MB synchronous, 12 MB async
  6. Response size limit: 6 MB synchronous, 12 MB async (only applies to response data from Function sent back to Apex).
  7. Same Salesforce web service API call limits per org (they count during beta, this limit will increase when Functions is GA).
  8. The infrastructure for Functions compute environments is located in US regions currently. This means that Functions (if your org was in EU/APAC regions) will access your EU/APAC region org data from the US.
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .