Suraj Pillai is a Salesforce Architect and Senior Developer at Vertex Computer Systems. He has done a variety of projects around Apex and lightning web components in his career. Today we discuss many of them.
Throughout our conversation, you will also hear a lot about using JavaScript with Flow and utilizing constructs like universal mocking. We even broach the topic of how you can get work done really quickly using Neovim. Tune in to learn more from Suraj.
Show Highlights:
- All about Suraj’s journey with Salesforce and his current job.
- What got him into JavaScript.
- What sparked the idea for his repo and what it does.
- Use cases for using JavaScript and local action to improve flow.
- Real-world examples for using JavaScript buttons.
- What Apex Mocks are and their benefits.
- The tooling he’s been building around Neovim.
- Some of the work he’s done with external services.
Links:
Episode Transcript
Suraj Pillai:
The things that I prefer lightweight, I prefer portable and I prefer performant.
Josh Birk:
That is Suraj Pillai. A Salesforce architect and Senior Developer over at Vertex Systems. I’m Josh Birk, your host with the Salesforce developer Podcast. And here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk Suraj Pillai, a variety of projects that he has done around Apex and Lightning Web Components. You’re going to hear a little bit about flow, you’re going to hear a little bit about universal mocking and you might just hear how he gets a lot of the work done, really, really quickly using Neovim. But we start, as we often do with his early years and his first memory of a computer.
Suraj Pillai:
My earliest memory would be, I think this was probably when I was 10, 11. Maybe somewhere under, or maybe even little younger than that. One of my cousins had gotten an old, this monstrous, black and white computers recently. And I saw, that’s when I saw it for the first time. And I started playing some of those old black and white text based games. And I just loved it. I was addicted. You couldn’t get me away from the computer. So, that’s my [crosstalk 00:01:20] memory of a computer.
Josh Birk:
So are we talking like Zork or were you like a classic adventure guy? What was your first text adventure game?
Suraj Pillai:
I think it was a game, if I remember correctly, it was a game called detective. Where they would give you a mystery to solve, and then you would be presented with some text describing the situation and then they would give you three options. Okay. Where do you think the burglar or the killer could be? Is it in, A, a gym. B, supermarket. C, wherever. And you have to use your clues that you’re given beforehand to figure out where they would be. So, that was the game.
Josh Birk:
Nice. And then when did you start developing with Salesforce?
Suraj Pillai:
I think 2013 is the year when I really started developing at Salesforce. Before that, I think the first time I heard of Salesforce was somewhere around 2011. But that was when I didn’t really know much about the cloud or I hadn’t really gotten much into it. And I took a brief look at it and it didn’t really make much sense to me at that time. I was like, yeah, it’s probably not worth my time. And I was super into programming, Java and all that. So then I came back to it because I was hearing more and more about Salesforce and all the conversations and communities and stuff came back to it in 2013. And that’s when I really started diving into it and getting trained and learning about it more.
Josh Birk:
Got it. And describe your current job, Suraj.
Suraj Pillai:
So currently I am a Salesforce architect and Senior Developer at Vertex Computer Systems. So as part of my job, a lot of my job is working with customers directly to figure out what their requirements are and to build the solutions or design the solutions and talk through the requirements and figure out that they’re not digging themselves into a trench with the requirements they come up with, to put in mildly. But yeah. And then of course, coordinating with the rest of the team, figuring out who needs to do what and doing a lot of the hands-on stuff myself. That’s in a nutshell what my job would to be.
Josh Birk:
Got it. How would you compare learning and getting into Salesforce compared to the earlier stuff that you did like learning Java and C++?
Suraj Pillai:
Yeah, that’s a really good question. So Java and C++, so when I was learning C++, I had no programming background and I don’t tend to be an expert in C++, but it was all very novel to me. So I don’t necessarily think I would compare that with the rest of the journey. But learning Java, there’s a lot to learn obviously. So you kind of like learning it step by step, you have to go slow, you can’t really start building a whole full fledged application on day one. You have to really go slow and try to learn the concepts really thoroughly before you get into it. The Salesforce, having that Java background, learning Salesforce, I would say was a lot more easier.
Josh Birk:
Okay.
Suraj Pillai:
Because I mean, once you get past the initial mental block of, okay, what is this thing doing and how is it structured, once you get that basic abstract down the rest of this stuff just becomes easy, at least from a bigger perspective to make sense of, okay, what is this whole thing I’m playing at?
Josh Birk:
Got you. You had that kind of blueprint of Java that you could kind of cast onto Apex as you were learning it.
Suraj Pillai:
Right, Yeah. When I was running Apex, it seemed like a very trim down version of Java. And so, I mean, it can be a positive and a negative. So, if I was learning Apex before learning Java, I might have paid more attention to detail and tried to spend some time learning the core concepts a little bit more, but having a Java background when you read Apex code, it just kind of makes sense. And you’re like, okay, this is how it’s done and all that. But I think that, that might have hurt me at least in the early years, because I didn’t really spend enough time learning a lot of the core concepts the way it should be.
Josh Birk:
Got it. Got it. Now. Okay. So C++, first of all, jumping into C++ for your first programming language, congrats. That’s definitely hitting into the deep water of the pool to get things started. But C++, Java, Apex, what got you into JavaScript? Was it just like you wanted to become more of a Full Stack developer?
Suraj Pillai:
Actually, this goes back a little bit to the very first project that I was a part of. And we did lot of Java work, but also there was some Front-End HTML facing work, and then there’s a lot of database and Shell Scripting as well. What particularly interested me about JavaScript was one fun application that I built. I was working on my first project. So we had this ticketing system that the client would use to create tickets. And every time a ticket gets logged, our project managers, whoever was in charge of the ticketing system that week had to log in, they have to constantly keep refreshing to see if there’s a new ticket and then they would have to assign it to the respective team.
Suraj Pillai:
So, this was around the time that I started getting my hands dirty with jQuery. And I was like, why don’t I build something using jQuery that just constantly pulls the system for new tickets, just grabs the HTML, uses regular expression to look for the ticket number, if there is a new ticket, then just pop up an alert or whatever, instead of someone having to manually keep refreshing the page.
Josh Birk:
Got it.
Suraj Pillai:
And that was one of the first JavaScript applications I built. From there there was no looking back. I mean, I was just completely mesmerized by JavaScript.
Josh Birk:
That’s awesome. What are some of your favorites now? I’m assuming you’re not still tinkering out with jQuery. What’s some of your favorite libraries to leverage.
Suraj Pillai:
So LWC is obviously the library that I work with the most that I really like it.
Josh Birk:
Nice.
Suraj Pillai:
React, I have dabbled with it, but I’m not a huge fan of JSX.
Josh Birk:
Okay.
Suraj Pillai:
So, I wouldn’t say React is my favorite library. My favorite library recently has been Svelte. I’ve been learning more and more about it. And like how it doesn’t try to do too much, but also just gives you enough to do your work. And, at least to me, it seems quite similar to LWC as well. So I like Svelte.
Josh Birk:
Nice, nice. I have always leaned to those as well. I think largely because I don’t write huge web applications anymore. So it’s like, I always feel like the ability for a React and Angular almost feels like overkill for me, but the smaller ones, like Vue and even LWC have always felt like a better fit as well. So I hear you. I hear you.
Suraj Pillai:
Yep.
Josh Birk:
Now tell me a little bit about this repo that we’re going to try to get some highlights on, what started you down a path of like, were there tipping points where you’re like, this is too much of a pain point. I want to build something better that helps improve this functionality and that I also just want to share this out to the world.
Suraj Pillai:
Yeah. So this repo that we’ve talking about, I assume you are referring to the LWC Apex module, the repo. And that repo has a very interesting journey. It started out when flow local actions came out first and that’s where you can build an Aura Component, throw it into a screen flow and have it execute some JavaScript on the client side. And something sparked an idea in my head and I was thinking, why can’t we generalize that and build a component that can take any JavaScript as an input, and then just execute it in a screen flow. And you could use that if you were dealing with collections or arrays or whatever in a flow, and you wanted to quickly transform it using one of the JavaScript functions, array functions map, reduce, filter, whatever, you could do that real quick without having to build a whole component for it. You can do that on the fly. And so that’s where the any-js local action repository came out of.
Josh Birk:
Okay.
Suraj Pillai:
And from there on, the next project that kind of led to was, attempting to create JavaScript buttons in LWC.
Josh Birk:
Okay.
Suraj Pillai:
I’m sure we have all used JavaScript buttons at some point in Classic. And when we came to Lightning that was one thing, at least initially, that we all so really missed. And I figured that there was a way to bridge that gap by building an LWC that could take a generic JavaScript as an input and do whatever you wanted to do with it. But then it also needed to have all those additional APIs that you were used to in Classic that allowed you to interact with Apex, allowed you to interact with Soko and DMLS and all those things.
Suraj Pillai:
So I built those into that library as well. And that’s how the JS buttons library was born. And then I kept adding functionality to it slowly. So it is quite feature-rich, I would say in terms of the APIs available, you can do Apex, you can do Soko, you can do call-outs, you can call out using name credentials from JavaScript itself, and you can also call out to your internal Salesforce APIs without having to do anything else. And you can call out to external services, I mean, not external services as we are used to in flows, but just in general, any external APIs using the fetch API as well.
Suraj Pillai:
And then from there on, after I had spent some time with the repo, eventually I got to a point where I was thinking, why can’t I make this more developer centered since I don’t think admins are going to be writing a whole lot of JavaScript, why not take this JavaScript button concept and then just build a speed of LWC modules that would allow developers to just import those into LWCS and avoid having to write Apex just for doing some Soko or some DML, or just for using name credentials or whatever, you wouldn’t have to write Apex anymore.
Suraj Pillai:
So that’s kind of where that idea stemmed from and led to this repository that you’re talking about.
Josh Birk:
Got it, got it. Okay. So a few follow up questions there. Like those first two things that you were talking about, like being able to create local actions and then JavaScript buttons. So, in both cases, you’re encapsulating JavaScript into a handy little container that can be accessed either through a flow or through a page. How much overlap is there between those two projects?
Suraj Pillai:
Between the first two projects, there’s only a very small overlap, mostly because the first project, the any-js local action project is a very small project. There’s only one local action that just takes the JavaScript and executes it. It’s a very tiny project, but there is a lot of overlap between the second and the third projects. The JavaScript button project, and the modules project.
Josh Birk:
And the modules project. So, sticking a little bit to the first one, give me a real world example of using JavaScript and a local action to improve a flow.
Suraj Pillai:
All right. So let’s say you wanted to, I mean, this is an example that I have in the repo. So let’s say you wanted to build a list button that you wanted to put on a list view where users can select multiple records, click on the button, which calls a flow, which in turn goes and does something with those records. Now, the example that I have up there is, let’s say, we selected a few records and you want to process that in flows, you would have to loop through those records. If you wanted to manipulate it in some way, you have to loop through those records, create a loop element. And within the loop element, you have to do some assignments. And if you wanted to filter something based on certain criteria, you would’ve to do decisions. So it adds a little more complexity from that perspective to the flow, whereas if you were to use any-js local action, what you could do is just serialize the records that you’re getting and use JavaScript to manipulate it, just add attributes to whatever de-serialize it, and then do your DML.
Suraj Pillai:
So there’s no loops, it’s a very straightforward flow and JavaScript has a lot of handy RA functions to handle your collections. And the other use case, I would say, the one that I have used it most often for is to redirect a user at the end of the flow to whatever page they may want to go to. So instead of having to write local action, to redirect them to a certain page, you can just throw this in, do a window location and take them directly. So it becomes an all purpose tool to have in your kit.
Josh Birk:
Got it. And I’m assuming that’s probably a bit of a performance increase as well.
Suraj Pillai:
I haven’t specifically measured performance, but that would make sense because there’s a lot more done on the client side with JavaScript, which we know is performance for the most part, especially when you look at the small data sizes and you take into account the network lagged. Yeah. I would think so should improve performance.
Josh Birk:
And tell me a little bit about the input-output there. What is JavaScript seeing in that sense and what are some of the things that it can influence? Obviously it has access to DML to a certain extent. Does it have the same scope as the buttons library where you could do things like call outs or stuff like that?
Suraj Pillai:
No, the local actions library is very limited. It doesn’t have access to any of the additional Soko or DML or anything. It’s very strictly just for doing any kind of client side JavaScript processing.
Josh Birk:
Got it. Nice. Nice. Okay. So let’s talk a little bit more about the JavaScript buttons themselves basically actually, same question. And so I assume there might be a same kind of answer, but what are a couple of real world things that you’ve done with it?
Suraj Pillai:
So I have used it mostly for prototyping. So some of the real world examples that I’ve actually built in the repo and I’ve used it also is let’s say, since I have access to Salesforce APIs, there’s a lot more I can do with it. For example, if I wanted to build a button for the admins to delete all the inactive flow versions, I can throw that quickly in JavaScript, I can use the Tooling API, I get the inactive flow versions using a Soko query, and then just look over and delete those. I have also played around with composite API in there to create related records with a single button click.
Suraj Pillai:
There’s some other prototyping I’ve done is if I wanted to create some seed data in an org, for instance, I can call out to APIs such as, I forget the name of the API, which gives you the user details. I can call that API, get contact details and quickly create contacts within an org. I think it’s called randomuser.me or something.
Josh Birk:
Okay.
Suraj Pillai:
Mostly for prototyping is what I’ve used it. But there are some limited real world examples or usages for it as well. Especially if you use the APIs, the Tooling API, metadata API, et cetera. Not metadata. Sorry, just the Tooling API.
Josh Birk:
What are you doing with the Tooling API?
Suraj Pillai:
The Tooling API, like I was saying earlier, I used it for fetching inactive flow versions, and deleting those. I have used the Tooling API for fetching debug logs. If I wanted to clear out the debug logs from the system. That’s a handy way of doing that as well.
Josh Birk:
Got you. Speaking of the modules that work with it, are there modules that you would like to see added to the future?
Suraj Pillai:
So, yes, right now I am working on adding platform cash module to the repo. It’s actually there in a separate branch within the repo. I have yet to write some more tests before I merge it with the main branch, but that’s something I’m working on. And then in the future, I might add some modules for working better with custom metadata and stuff.
Josh Birk:
Okay.
Suraj Pillai:
I mean, we can already do that using the Soko module, but, if I wanted to leverage [crosstalk 00:17:30] I could do that.
Josh Birk:
Yeah. Or skip a step and just talk directly to it.
Suraj Pillai:
Right. Yep.
Josh Birk:
Nice. Nice. Okay. So how easy is it to create those modules? Like if there’s somebody out there who’s thinking, oh yeah, that’d be something really cool I’d like to add. What’s the level of complexity to creating a new one?
Suraj Pillai:
It is fairly easy, I would say. You just have to understand the general structure of the projects. So basically each module is its own independent thing that does whatever it needs to do. The main focus would be the API as visible to the end user and the API as visible to the core module that’s importing our core LWC that’s importing all these additional modules into it. So how you structure the API is most important.
Josh Birk:
Got you. Nice. Nice. Okay. So let’s talk about another one of the things that you have up on GitHub. And mocking is something that’s come up on the show many, many times. You have your own version of an Apex mock, what’s the elevator pitch for that? How does that specifically work for you?
Suraj Pillai:
So universal mocks was based out of a need to make mocking a little bit simpler. For me personally, because I’ve worked with Apex mocks in the past. I’ve used it in some limited fashion in some projects. However, I found the library to be a little huge for smaller projects. That’s a lot of code and there is some aspects of the API that I am not too thrilled about. I understand why it was done. And it closer resembles Marketo and stuff. But I felt like there was a way we could make it simpler and that’s what universal mocker attempts to do, but it sacrifices some of the strong typing that we get with Apex mocks in favor of making the API a little bit simpler to use and understand.
Josh Birk:
Got it. So you were looking for something that was a little bit more lightweight and tailored to just what you needed, so to speak.
Suraj Pillai:
Exactly. It’s just a single class, anyone can go there, you don’t even have to download the whole repo, just copy the class, put it in your code wherever and you should be good to go. And the API is really simple to do. It’s almost reads like PROS, just mark when this, then return this. It’s as simple as that.
Josh Birk:
Got it. Nice. Nice. Now, speaking of rolling your own, you prefer Neovim over Visual Studio Code, and you’ve created your own tooling set around it. First of all, why the lean/preference to a pure CLI approach?
Suraj Pillai:
So you might have noticed this theme in everything that I have talked to you about so far. That the things that I prefer lightweight, I prefer portable and I prefer performant. These three things are what I look for above everything else. Above features and above being able to handle more use cases. And I had dabbled with them since 2012, 2013. However, it’s really when I got a Chromebook for the first time.
Josh Birk:
Oh, okay.
Suraj Pillai:
That the fact that, even though I was a Salesforce developer and we are all about the cloud, that fact that I couldn’t just go into a cloud ID and start building, and I’m not counting developer console, but the fact that I couldn’t just go into a cloud ID and start building and do my source control and all that really hurt me. And I wanted to be able to just go to any machine I want, just use a browser, log in to my ID and then just be able to code. And that’s where I figured the only way I could do that is if I went to a terminal based IDE and Neovim was kind of the natural choice since I had worked with it in the past and I spent a lot of time making it work for Salesforce and the CLI was really a godsend for that.
Josh Birk:
So first of all, I can completely understand somebody who likes lean and simple, probably not favoring the developer console. I can totally respect that, I could totally respect that. Now, so the CLI was a godsend, so you were attempting to go through this prior to the Salesforce DX “revolution”?
Suraj Pillai:
Yes, I was. So, I mean, I guess when I started with Salesforce development, the only option we had was the force.com IDE. And even though I had used it for some projects, I wasn’t entirely happy with it. In fact, if you won’t judge me, I’ll tell you, I would often prefer developer console over force.com IDE because I just did not like the bloat. I did not think that Salesforce was that complex of a language with these many libraries that we have to use such a bloated IDE to work on it. And so I had been working on just using developer console on occasion I’ve used MavensMate, but there was some things I was not happy about it as well. And then when I discovered the force.com CLI, that’s when it clicked for me, oh, wait a minute, I can do this using a CLI, I can make it [crosstalk 00:22:49] something and the force.com CLI was just really great. It was an eye opener for me.
Josh Birk:
Got it. So you basically got on the bus from day one. Like pre Salesforce DX were talking force.com CLI and that tool kit of being able to create an update and delete resources on your org.
Suraj Pillai:
Right, right. Yeah. I didn’t have to actually log into Salesforce to be able to use it from my local machine. There’s a great force.com CLI extension by John Aaron Nelson that works with VS code. Ever since the VS code beta came out, I had been using that because VS code also has the integrated terminal. It has add that from day one. And so that’s what I liked about VS code and VS code is a great idea. I mean, I use it still from time to time, it’s [crosstalk 00:23:36] enough and it has a lot of features.
Josh Birk:
Yeah.
Suraj Pillai:
And I had been using that when Salesforce DX came out and yeah, Salesforce DX is also a game changer too.
Josh Birk:
Got it. Well, tell me a little bit more about the tooling that you have been building around like Neovim so that you can pull up documentation and stuff like that.
Suraj Pillai:
Right. So one of the things I like about the CLI is that it has a lot of commands. It follows a specific pattern when it comes to those commands, the Oakleaf design pattern and also the fact that it’s being constantly updated, there’s a lot of plugins you can get for it to do very specific things. The thing that I do not like about the CLI is how Verbose off the commands often get. And especially when you add the flags to it. And there’s just a lot to keep track of. One thing I had always been looking for is a robust auto complete for the CLI and since I was working mostly, in Windows and Linux, I’ve never found the CLI auto complete to be the reliable, at least back when it launched.
Suraj Pillai:
I never found it to be too reliable and it was a hit or a miss as to whether it would work or not. And so that’s when I built my first auto complete script, you’ll find that in the repo as well for partial and it works great. You can type in a command and it will autocomplete for you along with all the flags. And that’s great for PowerShell. But then since I was working mostly on the Linux side, I needed something more that would not just allow me to autocomplete commands, but also allow me to look up commands just by kind of fuzzy searching through it and give them help manual as I am searching for it. And that’s where the SFDX script was born. SDFX for those who may not know is a fuzzy command line finder that uses grep, or one of the other find tools available with the CLI to fuzzy search through a list of things, anything pretty much.
Josh Birk:
Got you. And this is a podcast, so it’s a little hard to visualize, but you showed me this and one thing I can confirm is that it’s also, it’s really, really fast. Like it’s impressively quick when you pull that up on the UI.
Suraj Pillai:
Absolutely. You know, for when I have to write a circle query, I don’t even think about it. All I do is control and Q and the query is right there. And I just, before I know it, I’m writing my query away on the command line. So it’s made life so much easier for me since I built this. Even when I install plugins, I can add that to the autocomplete as well. And I just use natural language source to just find the commands I need and look up all the command details, the switches, everything, and just type it without ever having to leave my terminal.
Josh Birk:
Nice. Nice. Okay. So straying away a little bit from Apex, JavaScript, et cetera. Although I guess we’ve basically focused on mostly JavaScript, but anyway, going a little bit down the road, you have some, also some stuff with external services. What have you been working on there?
Suraj Pillai:
Yeah. So towards the end of last year, I had some free time and I was, I turned my attention to external services a little bit because when external services came out, I was super excited. I felt like there was a lot of potential there and there’s a lot we could do with it, but I was kind of a little disappointed to see that, it didn’t take off more and it wasn’t getting as much adoption or love with the subsequent releases. And when I started working in MuleSoft sometime last year or the year before that, that’s when I realized the power of RAML being able to define, use RAML to define your API specifications, translate that to OAS and things like that. And I figured why not use that with external services to make any API work with Salesforce and any API that you want, even if it doesn’t have an open API specification schema document or whatever, you can actually create that using and RAML and MuleSoft’s API design center, which is free for anyone to use by the way.
Suraj Pillai:
So you can just go in, it offers great support for building your own RAMLs, autocomplete, proper syntax, highlighting the words, everything. And after you’re done, you can just convert that into an OA specification, import it into the Salesforce and use that to basically call any API that you want. And I played around with that quite a bit. I wrote an extensive readme in my GitHub repo about that as well. Worked with various Salesforce APIs and external services to see how you could use external services and communicate with any of the Salesforce APIs that you wanted.
Josh Birk:
Got it very, very nice. Is there anything else in the repo you want to give a shout out to? I mean, or your GitHub in general?
Suraj Pillai:
So back when the CLI had just come out and I was using that for building one of our ISV apps, one of the things that was kind of solely missing was the ability to generate a package out of your changes, out of your git diff, going from one commit to the other and this was, I think back in 2017. So when I, I looked out there, there didn’t seem to be anything out there at that time. And so I wrote the script for packaging, your diffs into a deployable package, which you can then use the source deploy command or DMW deploy command to just deploy that. So that script I kind of like. It’s a very simple script, so it doesn’t handle deletes because I didn’t want script deletes, but it handles everything else, additions, modifications, renames and all that. And I know there’s the SFDX Xcalan, I think is the name of the package that does the same thing.
Josh Birk:
Got it.
Suraj Pillai:
But the script that I have, again is small, lightweight, compact, and it does the job.
Josh Birk:
Nice. Is there a project you haven’t started yet that you want to?
Suraj Pillai:
There are actually a couple of projects that I’m working on that need some more work. I mean, okay. I’ll talk about it. So basically what, one of the projects that I’m working on right now is called Multi-Picklist Helper. And what I’m trying to do with that is build a robust solution that can take your Multi-Picklist values and create related records out of that so you can report on those better. So it’s basically, it should be able to handle any volume of data that you have in your org by using queueables and batchable and all that, and create related records in a custom object. So that’s kind of a side project that I’m playing with right now.
Josh Birk:
That’s our show. Now the show notes will have links to Suraj’s wonderful GitHub repo. Be sure to go check that out now. Before we go, I did ask after Suraj’s favorite non-technical hobby and turns out it’s inspired by a little known Netflix show.
Suraj Pillai:
So my hobbies keep changing from time to time, but ever since last year, I guess ever since the Queen’s Gambit dropped, I’ve been rediscovering my love for chess.
Josh Birk:
Really?
Suraj Pillai:
I used to play chess as a kid for several years but then I stopped. Life got in the way but since last year I’ve been playing more chess and trying to slowly get better. So I watch a lot of chess videos and try to get better at it. That’s kind of my hobby these days.
Josh Birk:
I want to thank Suraj for the great conversation and information and as always, I want to thank you for listening. Now, if you want to learn more about this show, head on over to developer@salesforce.com/podcast, where you can hear old episodes, see the show notes and it links to your favorite podcast service. Thanks again, everybody. And I’ll talk to you next week.