Honestly that bothered me more than a perky product owner up in my grill on a 8am standup after the dev team worked all weekend because said product owner can’t say no.

So I looked at myself in the mirror through a fork - turns out I don’t look good behind bars - and wrote this. So lets all sit around this dumpster fire and discuss JavaScript concurrency! This quest has three chapters.

🔄 Chapter 1: Callbacks (aka The Ancient Times when jQuery ruled the web and XMLHttpRequest was a novelty)

Back then, JavaScript was a relative babe, and as we all know from the Christmas songs, you have to wrap the babe in swaddling clothes - or in this case, callbacks. That led to developers writing callback hell. Yo check my comments here.

getAccount(accountId, function(account) { // getAccount()'s second argument is an anonymous function. AKA Callback. This anonymous method is executed by the JavaScript overlords when getAccount is finished.  
    getContacts(account.Id, function(contacts) { // Also uses Callbacks
        getOpportunities(contacts[0].Id, function(opps) { // If you guessed also a callback, you win.
            // Welcome to the pyramid of doom!
            // Population: Your sanitys
            // Work harder, no one cares.
        });
    });
});

We called this "callback hell" for a reason, folks. I once - and I can’t make this sh*t up - saw a function that had 33 nested callback methods. In a textbook. My therapist reminds me to go pet the dog at times like this. 🐕 If you’re wondering why this is terrible - well, I mean it works but that’s about the only bambi-kind thing I can say about it. This gets hard to break into maintainable-sized-methods and just … understanding the flow can be a challenge. Sure there were things you could do to de-structure this by calling named functions instead of anonymous ones, but … I don’t remember seeing a lot of that.

⚡ Chapter 2: Promises - The Betamax of JavaScript

So we hated on Callback hell an Promises came along and were like "Hold my coffee." ☕ Honestly most people were like ‘wtf is a promise’? Promises have a bit of a marketing problem. First, it’s a word that’s abused by politicians, managers everyone knows that PM. Secondly, it’s not sufficiently esoteric that you can Google it and get a very narrow set of explanations. Seriously, try Googling Promise; Yeah. Now try Googling ‘monad’. I’ll wait. See the difference? Personally, I think we should have called Promises ‘monadic composition’. Cause that’s … clearer. Check out this code while pondering my sanity.

getAccount(accountId)
    .then(account => getContacts(account.Id)) // look ma, no callback methods!
    .then(contacts => getOpportunities(contacts[0].Id)) // OMG None here either!
    .then(opps => {
        // Look Ma, no pyramid!
    })
    .catch(error => {
        // One error handler to rule them all
    });

Ok so the key takeaway for promises is this: A promise provides flow control (try/catch) for asynchronous work by allowing you to attach work - functions - to be executed after the previous step concludes. Promises use the then method to chain work together. Grammatically it makes sense right? do this, then that, then this other thing… Still not sure why they’re called ‘Promises’ but there’s a whole heap of JavaScript that falls in to the ‘WTFJS.com’ bucket. Honestly, JS as a language has all the hallmarks of a circular family tree, but … I don’t care what people say, I say it’s sweet.

Regardless of naming issues, Promises make our lives easier if for no other reason than there’s much less code to reason about. They’re also … just conceptually simpler. Once you grasp the language guarantee that each then() function is blocked from executing until the previous one completes… you’re good to go.

This is, as they say in my hood, ‘much better’. But let’s be honest, it feels a bit like someone shoehorned that into the language. (oh wait…) I mean, wouldn’t it be nice if the concurrency framework was keywords or operators instead of methods?

🌟 Chapter 3: Async/Await - The T.S. Evermore Era of JavaScript concurrency (Her best era. There, I said it.)

Async and Await are keywords. Inside any method that you’ve prefaced with async you can use the await keyword

Here's the plot twist Broseph: Async/Await isn't new bbq sauce - it's just lipstick on the promise of a pig. AKA Promises wearing a really flattering Chelsea jersey. Check my comments yo.

async function getAccountData() { // <- we start with that async keyword. 
    try { // but wait, what's this? more on that later larry.
        const account = await getAccount(accountId); // see that await? that stops execution of the following lines until it's completed. 
        const contacts = await getContacts(account.Id); // Yep, another pause.
        const opps = await getOpportunities(contacts[0].Id); // one more pause for good measure.
        // Same Promise chain, but reads like synchronous code! 
    } catch(error) {
        // Still just a .catch() under the hood which is how we can use a try/catch with async code
    }
}

So here we got some asynchronous code that reads like synchronous code. And that’s pretty badass. Here’s your key takeaway for Async/Await - It allows developers to write Async code that reads Synchronously. Keep in mind that every await keyword means the rest of the method is paused until the await’d line has completed (or errored out).

I, for one, think this is the only way one should write Async JavaScript. And honestly, you’ve read this far, so you must think this dog can hunt. But in my head (and inbox) I’m hearing people complain that Async/Await and Promises do different things so… Ok Broseph… here’s how Async/Await works under the covers: Every async function actually returns a Promise. This is literally(Yeah, read that with an exasperated valley accent) the same as our Promise example above:

// These are functionally identical!
async function getData() {
    return await fetchSomething();
}

function getData() {
    return Promise.resolve(fetchSomething());
}

🖖 So what does this mean for you?

If’n your a Salesforce dev writing some mighty fine LWC’s - you should use Async/Await. Anything else makes Codey Cry. Seriously, like you rubbed his eyes with onions. Just Bawling. Don’t do it, he’s not done nothing to deserve it. Even the creepy animatronic version.

Today You learned? You can Await your imperatively executed wire methods. const foo = await myPreciousApexMethod()

Next time someone tells you Promises are better/faster/stronger/different than Async/Await, ask them if they’re interested in signing a petition to ban dihydrogen-monoxide…

Thank you for coming to my ted talk, and remember only you can prevent stupid code.

🌟 Cue dramatic music 🌟

Introducing Universal Invocable[1], the elegant solution that lets developers expose multiple Apex methods to flows without drowning in a sea of tiny, one-method classes. Say goodbye to the days of writing one-class-per-invocable-method. Universal Invocable is here to save the day!

But hold onto your developer hats, because harnessing the power of Universal Invocable does require a (teensy) bit of effort. You'll need to extend your classes with the provided UFInvocable class, masterfully patterned after Salesforce's own Callable Interface. Don't worry; this hero class is fully bulkified, enabling your flows to call multiple Apex methods from the same Action element!

🚀 Explosions in the background 🚀

But that's not all! Universal Invocable comes equipped with the incredible UniversalInvocable Invocable Action. This action is your trusty sidekick, capable of calling any Apex method from classes that extend the UFInvocable class. Together they're an unstoppable duo, ready to conquer any development challenge in their path!

🌠 Epic montage of developers coding 🌠

To get started on your own heroic journey with Universal Invocable, head over to the source code. For some light, and totally not dry, reading on the Callable Interface, UFInvocable's soul sister, consult the Callable Interface documentation.

🚨Shut up and take my money! 🚨

For now, the installation instructions are simple: manually copy the Universal Invocable classes from the source link into your org. Be sure to snag the example Flow to get a sense of how to invoke this from Flow! (this is not a paid product. It’s open source, and freely available here.)

🔥 TL;DR; 🔥

Who is this for? Salesforce Developers who want to expose Apex methods to Flow without littering their org with a ton of Single-method classes.

What does this do? Establishes a ‘universal’ way of invoking almost any Apex code from your org through a single InvocableAction.

Seriously? Hell yes. You just need to extend the provided UFInvocable class and create the call() method.

What doesn’t it do? Slice, dice, and roast chickens work automagically without you having to do anything. You, a Salesforce developer, will need to add a small bit of Apex to the classes you want to expose, but this should be less work than generating a one-off, single-method @invocableMethod classes.

💳 Who made this? 💳

Listen, y’all. Back in August, I was laid off. I’ve been putting some of my (f)unemployed time into documenting and building on my pet project - ApexKit. I had the idea for Universal Invocable and put together a prototype using the Callable interface. I asked Brian Fear - better known as sfdcfox - to give me a code review, and not only did he fix my stupid dyslexic typos, but he also hit upon and implemented the bulkification that enables you to call multiple Apex methods from the same action block. In short, he took my Awesome idea (™) and made it positively Epic. If you’ve not heard, Brian is also (f)unemployed at the moment. If you like Universal Invocable, please consider throwing some love our way.

If you feel so moved, please do boost this post, and here’s our relevant information:

Brian Fear, aka SfdcFox

Paypal: brian.m.fear@gmail.com
Venmo: brianmfear
Buy Me A Coffee: brianmfear
Zelle: brianmfear@gmail.com
Cash App: $BrianFear

Kevin Poorman, aka Codefriar

Paypal: kjp@codefriar.com
Venmo: Kevin-Poorman
Buy Me A Coffee: Codefriar

[1]: Look, naming things is hard. I wanted to name this Project Hulk. (Because Hulk is easily the best Avenger. After all, he’s had a traumatic accident that granted him superpowers that he’s only able to access while he’s struggling with the worst aspects of himself, and he’s still attempting to do good for the rest of the world.) But well, Marvel said no. ¯\(ツ)/¯