Episode 123: Salesforce Development with Dan Appleman Pt. 2

This is part 2 of our conversation with Dan Appleman, author, software engineer, and entrepreneur, where he shares some things he has learned about developing on Salesforce over the years. We pick up talking about his Advanced Apex book, which is now in its fifth edition, and what the new updates look like.

Dan notes that while there have been many new changes in Apex programming such as improved platform events and easier metadata updating, most of the changes are in the triggers. He also foresees the future of Salesforce development for any medium to large application.

Show Highlights:

Updates in Apex programming including triggers
Things to consider when creating a framework
Why focus on principles instead of frameworks
The question of modularization
The future of Salesforce development for medium to large application
Custom metadata driving a trigger dispatch system
The benefits of SFDX
The power of focusing on foundational concepts
Dan’s favorite presentations
What makes the process builder evil

Episode Transcript

Dan Appleman:
I went through line by line, chapter by chapter, making sure that everything is still correct.

Josh Birk:
That is once again, author, software engineer and entrepreneur, Dan Appleman. I’m Josh Birk, your host of The Salesforce Developer Podcast. And here on the podcast, you’ll hear stories and insights from developers, for developers. Today we continue and talk with Dan about the many things he has learned about developing on Salesforce over the years. We picked up talking about his Advanced Apex book, which is now in its fifth edition. And we’re going to take it right from that spot that we just heard, where he is going into what the new updates look like.

Dan Appleman:
Putting in fixes, improving samples and all of that. Then there were what I would call sort of the major changes. For example, the section on asynchronous operations is significantly enhanced because we have Transaction Finalizers. Right? Very cool. And I think the platform events has improved since last time. You have the immediate publish events did not exist on the previous edition. Things like how do you update Metadata from Apex has gotten a lot easier to build a UI around it because you don’t have to implement the whole [inaudible 00:01:21] thing. Right?

Josh Birk:
Right.

Dan Appleman:
In your lightning page. And also you can write metadata objects. You can write the fields, you can’t save them directly, but they’re not all read only, which means you can do things like it basically simplifies your ability to work with custom metadata, to create rappers around it, to build unit tests for it and so on. So a lot of those kind of changes, but the really big change, the thing that consumes most of the time, most of the new material is Triggers. The chapter on Triggers is a complete rewrite start to finish because they’re just better ways to do things. The world has changed. This is.

Josh Birk:
Okay. So, and because this is fascinating to me because first of all, you own biographical example of how you got into Apex Programming was a trigger. And I think that is so common that it’s like, we need this business process to work in this one way. We can’t write a flow for it or workflow or whatever at the time it was, we got to go get somebody who understands programming in order to write a trigger. I feel like outside of the Salesforce Ecosystem, it’s hard to impress on people how central triggers are to like a developer’s identity, almost like it’s. So there’s almost no way to go through your career without having triggers, like part of your staple. So I’m trying to think of the best way to ask this. It’s like, walk me through.

Dan Appleman:
All the things I had wrong before.

Josh Birk:
Right.

Dan Appleman:
I felt, I’m going through this chapter, I’m beginning to feel bad. It’s like, “Oh my God, people are going to read the old book and they’re going to follow that advice.” And I feel guilty’s like, was I wrong? Was I bad? It’s like, No, the world has changed. It’s not my fault.

Josh Birk:
Right. Right. Right. Well, and we’re going to clear on one thing that we had talked about before, because one of my pet peeves is when people are learning and teaching triggers and they’re doing it as single file and they’re not bulkified. And I think you and I have both agreed to like, no, no, all coach should be bulkified. At least you put people down that proper promo path.

Dan Appleman:
Yes. That from day one, I was like on my high horse saying all coach be bulk code. Don’t even teach single object patterns, because it’s just not worth learning them. So, it’s okay. Create a list even if you know, it’s going to be one record because it’s just better.

Josh Birk:
It’s just better.

Dan Appleman:
Yes, that hasn’t changed.

Josh Birk:
Yeah. It’s just better. Okay. So instead of focusing on the past, let’s focus on the present. How would you paraphrase the new chapter as to, like what’s a modern way of thinking about triggers in a proper application development or environment?

Dan Appleman:
All right. So where do I start? Let me start where I started in the chapter. Let’s talk about frameworks. People accuse me of creating a framework. Somebody would refer to it as my framework and I never, never created a framework. A book did not include a framework. I know it looked a little like a framework because it had certain interfaces. It’s not a framework because it was not production code. It was not production ready.

Josh Birk:
Got it.

Dan Appleman:
But people used it and people built all kinds of trigger frameworks and some of them are pretty cool. And the only problem I have with frameworks is people can get the idea that, oh, I’m going to be using triggers. I have to use a framework to do it, right. And that is a mistake on any number of fronts. Right? First of all, because not every framework suits every application because the framework that a large enterprise needs might be different from one that a small company needs. In fact, the smaller org may not need a framework at all.

Josh Birk:
Right. Thinking

Dan Appleman:
Thinking that you have to have a framework means people might think you should rewrite your application to use a framework. And you should never rewrite code, refactoring maybe. But starting from scratch is almost always a horrible idea. And the other thing I see and you got to understand, I see a lot of orgs. Right? We’re an ISV partner. We have a lot of customers. And when they run into problems, a certain set of problems, they call us because blame the managing package is sort of it’s a thing. Right?

Josh Birk:
It’s a thing, it’s a…

Dan Appleman:
It’s a thing. And sometimes it’s our fault. And most of the times it isn’t, but we help people anyway. But sometimes we see their code and sometimes we see code that is beautiful. I’ll go into an org, I’ll say, “Oh, I like these people. Right. They’re speaking my language.” And sometimes I’ll see a thousand lines of I plus to pass into the test, which I thought was legendary. Until I saw-

Josh Birk:
It until you see it yep.

Dan Appleman:
… in a large corporate or I cried. It was.

Josh Birk:
I know. And it’s like this legendary beast, except it’s not, and-

Dan Appleman:
It’s not.

Josh Birk:
It’s kind of like triggers. It’s also inevitable. Especially if you’re doing consulting or ISV work, you’re going to crack it open. You’re just good. I printed one out. One time. It had covered most of a poll in the office and I covered, I printed it out and I posted it and on top of it, I just wrote fireable offense.

Dan Appleman:
Yes, absolutely. I agree. 100%. But what I do see is I’ll see people using frameworks partly. Right? Which is to say somebody built it, they used the framework, but then somebody else came along or maybe a consultant and they started doing things outside of the framework, which completely screws things up. They’re worse off than if they never had a framework in the first place. So the first thing I really spend time talking about in the new addition of the book is to think about frameworks. Right? You don’t need to use the principles being taught here. You don’t need to use the framework to use those principles. Right? Think about the concepts and the ideas and how they might be useful in your situation rather than I need to adopt the framework. Right? Because that’s sort of like the they’re trying to take a shortcut. So that’s sort of the first thing I talk about.

Josh Birk:
Right. And I kind of want to emphasize that because it’s like, I feel like you’re saying, learn these principles and then go adopt something because then you’ll understand whether or not you should adopt something because you’ll better understand how the framework’s actually working.

Dan Appleman:
Right. You know how it is in software, anytime you’re doing any performance work, a 10% effort will give you 80% of the benefit. Right? So, if you identify your particular problem, you can just choose that one aspect of the trigger patterns. I present incorporate that and you’re good to go. You don’t need to waste time doing the rest. You have better things to do.

Josh Birk:
Right. Yeah.

Dan Appleman:
The next thing I spend, a lot of that actually influences the whole rest of the chapter is the question of modularization. Right? So people have probably already seen a number of examples and I certainly did not invent this of custom metadata driving a trigger dispatch system. Right? And the idea there is you can then have different sets of logical functionality built into packages. Right? And I know that there is a drive towards this idea that rather than building a giant monolithic, looking at your org as the monolithic happy soup, they call it. Let’s break it up into individual sections that can be represented by unlocked packages typically can be supported independently, developed independently, deployed and updated independently by different groups and so on. And that is the future of Salesforce development for any medium to large application.

Josh Birk:
Got you.

Dan Appleman:
And I embrace that.

Josh Birk:
Okay.

Dan Appleman:
Right. I think that is the future. I know some places are starting to do that. I think we have a long way to go.

Josh Birk:
And I think that’s really interesting because it definitely feels it’s like that conversation has started for a while, has been getting more sophisticated. And it kind of feels like to me, it’s getting to that tipping point where it’s really getting put to the test, because we’re starting to put them into things like large production orgs and things like that. So it’s like, it’s next evolution is ahead of it where it’s like, we figure out the things that we were doing wrong and we can get the next version of these frameworks out there.

Dan Appleman:
And this is.and hopefully the fifth edition of the book will be a support that progress, because what I do there is that’s my starting point is I say, Okay, now we’re going to look at everything from here on this whole chapter, we’re going to be modular. Right? We’re going to think about, you know, and yes, we’re not going to build unlocked packages because that’s too complex for a book, but we’re going to put them in separate SFDX directories that can be deployed separately that are decoupled from each other. Right? So, so the examples are built that way. I don’t want to use the word framework, but what does that architecture look like?

Josh Birk:
Yes.

Dan Appleman:
And the problem is that a lot of times when people build these kinds of solutions, they start with two principles that carry over from earlier additions of the book. And from earlier Salesforce development, one is the one trigger idea so that we can control trigger order.

Josh Birk:
Yep.

Dan Appleman:
And we get the idea that the handlers should be in classes, don’t build things into the trigger itself.

Josh Birk:
Right.

Dan Appleman:
But what is missed in, I think a lot of the approaches, a lot of the ways people are approaching this Metadata driven approach is that what you really need is more sophisticated than that. For example, you want each one of those modules to be able to have some of the benefits you had before, like you want centralized error handling, you want centralized control. For example, when one of your modules is doing a DML update, you don’t necessarily want any of your others to be taking any action on any triggers that occur.

Josh Birk:
Right.

Dan Appleman:
Right. Because the enemy is re-entrancy.

Josh Birk:
Right.

Dan Appleman:
Right. That is especially we can see few time our enemy is somebody does a DML that fires a trigger that trigger does a DML fires, a trigger, and then automation’s involved and you’re around and around then round. So yeah. And we see a lot of that.

Josh Birk:
Oh yeah. I think we’ve all been involved in what I like to call the murder mystery conference call where like five people are staring at the Debug Log trying to figure out which one of them fired the gun. And it’s just like, oh, that DML statement did it all.

Dan Appleman:
Exactly. So any sort of real sophisticated trigger handling architecture has to provide a mechanism for each of those modules to be able to say, “Hey, I don’t want to see our internal triggers. I want to see some internal triggers. I want to know who fired the DML so I can decide what to do.” Or when I fire this DML, I want to see the triggers that occur. I don’t want them to go somewhere else.

Josh Birk:
Gotcha.

Dan Appleman:
Trigger dispatching is far more sophisticated in the real world than just, oh, let’s have custom Metadata call a handler and a module. So I go into that a lot in a lot of depth.

Josh Birk:
I love it. Well, I feel like we’ve come a little bit full circle, because it’s like the way you’re describing the construction of this is very SFDX centric. So is this where you kind of go back to really do proper development on the Salesforce platform, learn SFDX and learn how your code is being constructed and deployed.

Dan Appleman:
Well, I think a first step, even if you’re not going to use packages is to break up your SFDX project into folders that represent. Right? It’s an obvious first step, but again, it’s a process. Like if I look at our own project, we only recently started to do that.

Josh Birk:
Yeah. Well, and I laugh because I remember my first panel interview, or my first series of interview is Salesforce. And I was talking to the product manager of apex at the time. And he was like, “Okay. My one question to you is tell me the five things that you would want to update to Apex.” And that he paused. He was like, “And one of them can’t be foldering because I hear that one all the time.” Like, because everybody who comes from other languages, is like I group things into folders where are my folders? And it’s like, we finally have a structure to bring it back to all of these other things that other languages have learned for so long.

Dan Appleman:
And really that’s what SFDX has done for us. Right? It has really brought Salesforce development into the world of Mainstream software development. If you’re coming in from another platform or language, you don’t have to be when people come in and I talk to them, I don’t have to be as apologetic as I was before saying, “Well, you can’t do this, you can’t do this. You can’t debug. You’ve got…” You don’t have to do that anymore. It’s like, we’ve got it.

Josh Birk:
Got it.

Dan Appleman:
So that’s a wonderful thing.

Josh Birk:
So a couple final questions. One is if I’m like a intermediate level developer, is there one other thing that you would want to shout out from the book that’s like, this will be the kind of thing that helps you go from being an intermediate level developer to an in advance level developer?

Dan Appleman:
I think it comes to the way you think about Salesforce and okay. The first part of the book is basically saying, look, here are the core concepts. You need to understand limits. You need to understand static variables. You need to understand bulkification, the concept of an execution context. Those are sort of the core of what makes Apex and Salesforce and not some other language. And if you have those down and really understand those you’re actually going to do just fine. Right?

Josh Birk:
Right.

Dan Appleman:
I sometimes say that an expert is someone who understands the fundamentals really well.

Josh Birk:
No, that’s good.

Dan Appleman:
So focus on those foundational concepts.

Josh Birk:
Nice. Now this is a total curve ball, but you’ve been doing this for so long and I’ll give you a moment if you need to think about it. So I have been accused of being the kind of person who asks questions that are basically like choose the favorite of all your children. But if you had to select one, what’s your favorite presentation that you’ve done?

Dan Appleman:
In the Salesforce world?

Josh Birk:
Yeah. Any.

Dan Appleman:
Okay. So I’ll tell you non Salesforce and I’ll tell you Salesforce.

Josh Birk:
Perfect.

Dan Appleman:
So my favorite non Salesforce one was when they first came out with it, wasn’t PowerShell, but was, it was in the windows world, the ability to use VBScript to automate things.

Josh Birk:
Okay.

Dan Appleman:
So there was a virus that was going around. I can’t remember its name off the top of my head. But it was a VBScript virus. So I grabbed the copy of it. I defanged it. And I started doing a presentation and while I was doing the presentation on the screen behind me, I opened this words doc. And on the screen behind me, it started talking about formatting hard drives and the emails, all these horrible things. That was basically script being scripted through this virus. And I take a look and like, oh wait, oh, no, oh my God, what’s going on? I’m freaking out. I say, no, it’s all a joke. Let me show you. And I walked him through the virus. I’ll say, look-

Josh Birk:
That’s awesome.

Dan Appleman:
…. microsoft’s just given this amazing power to script. Yeah, the operating system, but.

Josh Birk:
With great power.

Dan Appleman:
But with great power And the windows folks actually sort of yelled at me and they sort of said, Well, that could only happen if the person’s a system administrator. and I say, “Yes, and aren’t we all?

Josh Birk:
Right, nice.

Dan Appleman:
So user access control showed up soon after and antivirus got veteran and all that kind of stuff.

Josh Birk:
Perfect.

Dan Appleman:
So that was fun. Nice. I think the Salesforce world, I don’t know if it’s my favorite, but it’s one that comes to mind is one that I did with Bobby Watson, who was a guy who worked for us. And he’s now at Salesforce org where we did benchmarking the stark art of benchmarking. You can still find that on YouTube somewhere where we basically showed how you can not only benchmark Apex, but benchmark automation.

Josh Birk:
Huh.

Dan Appleman:
And it was the start of the process of basically saying, Hey, look, now that CPU time that automation counts on CPU time, you have to be able to benchmark it. And it was then beginning, but you know, later there’s been more, more done after that. I think there was a sequel to it. But basically I was one of the people who helped discover that process builder is evil. And when I say process builder is evil, let me be clear, from a developer perspective, from an admin perspective, it’s really elegant. It’s so useful and so on. Yeah. But the performance is awful beyond belief. And sometimes someone will say, “Well, I have the criteria so that it won’t actually execute.” And I say, “No, it’s the criteria that’s for length of time.”

Josh Birk:
And that’s our show. Now head on over to the show notes to find various links to Dan’s writings and teachings. Now, before we go, I did ask after Dan’s favorite non technical hobby. And it turns out he’s a fellow gamer.

Dan Appleman:
Well, I do some gaming. I have recently discovered Virtual Reality. I think I discovered during the pandemic. Right? Like everyone else, like I need to, I’m stuck indoor. How do I get some exercise? Right?

Josh Birk:
Right.

Dan Appleman:
And at first I used the Nintendo Switch. I can’t remember the game.

Josh Birk:
Oh, the cardboard, the Labo.

Dan Appleman:
No, not this wasn’t VR. It wasn’t a VR game. It was an exercise game whose name, it had like ring fit adventure.

Josh Birk:
Got it.

Dan Appleman:
And I did that for like the first part of the pandemic until all that running in place was starting to mess up my feet. But about that time I got an Oculus and it was for me a, just one of those, oh my God. Experiences. Because while it’s not ready, player one, I can see, I can see the future. I’m one of those people who think that like Facebook renaming themselves, Meta and going all in on that they’re geniuses. Right.? Because 10 years from now, I promise you. Okay. Just like when the web came out, everyone’s saying, what is this thing? And next thing every company has to have a website. Every company’s going to have to have its place in the Metaverse like a place you can visit and people walk into 10 years. Right. Maybe less.

Josh Birk:
Got it.

Dan Appleman:
And I discovered that putting on that headset, now I am outdoors. Now I am experiencing things. And there’s some wonderful games I play. Synth Riders is the game I play every day. For exercise.

Josh Birk:
Nice.

Dan Appleman:
So yes, I spend a lot. I spend what for me is a lot of time half an hour, a day in Virtual Reality. And it’s a life saver. So that maybe qualifies.

Josh Birk:
I’m with you. VR got me back into a relatively regular exercise regimen. Weirdly. I started it in VR. It had like, got me into the habit enough that now I don’t do it in VR as much. The other thing that surprised me is how calming I can find VR because it just disconnects you. So like, I love gaming for the flow state of it. And VR has that almost like to the next level. And so I still have a slew of games on the PlayStation for PSV, that’s my backlog. Whenever I just need an afternoon off from reality. Well, if you don’t have VR and you’d like a break from reality, you can always check out this podcast. And if you’d like to learn more and head on over to developer.salesforce.com/podcast, I want to thank Dan for the amazing conversation and information and is always, I want to thank you for listening. I’ll talk to you next week.

Show Highlights:

Links:

Episode Transcript