Episode 110: 2021 Apex Updates with Daniel Ballinger

Daniel Ballinger is the Director of Product Management for Apex. In his role, he spends the majority of his time balancing options and making decisions about what problems his team should pursue and which they can afford to wait on.

There are plenty of exciting things on the Apex roadmap for Daniel and his team right now. In this episode, we discuss some of these updates, including Data Wave and user mode database operations. Tune in to learn all about these new features and when you can expect to see them rolled out.

Show Highlights:

Daniel’s earliest experiences modding maps.
His earliest opinions on Apex.
What it takes to break something at Salesforce.
How Daniel and his team promote scalability, growth, and performance with transparency.
How Apex users can make Daniel’s job easier.
What Data Wave is and how to use it.
How big of a difference Data Wave makes in doing CSV to JSON operations.
What user mode database operations are and their benefits.
How to switch between safe mode and system mode.
The timeline for these Apex updates.

Episode Transcript

Daniel Ballinger:
In the background I was always tinkering with computers. And then when I actually got to university, it seemed like actually it was a better fit for me.

Josh Birk:
That is Daniel Ballinger, Director of Product Management for Apex here at Salesforce. I’m Josh Birk, your host for the Salesforce Developer podcast. And here on the podcast, you’ll hear stories and insights from developers for developers. Now, before we begin the interview, a quick message for everybody. I want to wish everybody a Happy Holidays to you, your friends, and your family. And a heads up, the podcast is going to be taking a small vacation while I myself get back in touch with my own friends and family and take a little break from work. But fear not, audience, I will be returning in the new year. Anybody who knows me knows that I’ve been loving this too much to stop now. So, have a Happy Holidays, and I will see you in the new year. Now, back to our interview with Daniel. We are once again going to start with his early years about modding maps.

Daniel Ballinger:
… To go into computing. I actually really enjoyed it. I was reprogramming the … I think at the time it was Duke Newcomb and Quake. I was altering the game code, re-compiling them. And I was actually using them a lot for my graphic design work, which was a funny model.

Josh Birk:
Oh, really?

Daniel Ballinger:
Yeah. It’s like doing house design, the Quake level editor.

Josh Birk:
Yeah.

Daniel Ballinger:
Still quite limited, but I quite enjoyed that part. I thought, actually, “This is the part I really enjoy, so I’ll go down the computing path.”

Josh Birk:
Inter … So, what led you … Because I am also a former modder and mapper of such things. And in those days, that was not terribly easy to go in and create those levels on those maps. What led you to want to use that for graphic design?

Daniel Ballinger:
At the time, a lot of the graphic design work was done on paper. So, we’d be doing on our drawing boards, and my drawing skills were not up to my design skills. So, I couldn’t always express what I wanted to do as well as people who were expert. My shading, and that was terrible. But my computer skills were above that, especially from previously tinkering. I was like, “I could do this easier in the computer and get a better result.”

Josh Birk:
Huh.

Daniel Ballinger:
And better express what I was trying to do through that. And then, of course, the more you do it, at that age, it’s like, “Oh, what if I do this? What if I do that?” And you start going down big rabbit holes and you have time to explore them.

Josh Birk:
I love it. I love it. What’s your earliest memory with the computer?

Daniel Ballinger:
Ooh. Earliest?

Josh Birk:
Yeah.

Daniel Ballinger:
Ooh. Commodore 64, I think.

Josh Birk:
Four. Nice.

Daniel Ballinger:
I don’t know, maybe earlier. It was Apple 2E. I remember, actually, Apple 2E, probably.

Josh Birk:
Mm-hmm (affirmative), Mm-hmm (affirmative).

Daniel Ballinger:
Writing basic scripts, like 10 print, something 20 go to 10.

Josh Birk:
Right.

Daniel Ballinger:
That was about … But you could manage that at primary school, and that was good for a laugh.

Josh Birk:
And then, how did you end up going from .NET and into Salesforce?

Daniel Ballinger:
I sort of got hooked in through the API, so somebody’s like, “Oh, we’ve got a service. We need to pull some information from the customer’s Salesforce, instance. They’ve got an API.” And I was like, “I can do APIs. I’ll pull the data out for that.” And we got that out, and then that project grew successfully. And then at some point we started to need to say, “Okay, we can get the stuff from the API, but we need some functionality to occur in Salesforce when we push data back in.” I was like, “Oh, okay.” So I can see they’ve got a coding language, okay. Java-ish. I can do that. I’ll write you a trigger, and we’ll modify the code. We’ll make an API on the Salesforce side. And then it sort of grew from there that I started expanding out from the API inwards into Salesforce, and then making triggers, custom pages, visual force pages grew from there.

Josh Birk:
So, kind of an integration centric, but then application building later.

Daniel Ballinger:
Yes. Yeah. And then at some point you realize, “Hang on. Some of this stuff makes more sense to do in the system than constantly talking out to an API,” and I built outwards from there.

Josh Birk:
Gotcha. Now, I know you from doing crazy mad science stuff like wanting to send Astro into space. By the way, any updates on that?

Daniel Ballinger:
COVID sort of put a halt to that, because the second you send something to space, where it comes back down is going to be a bit of unknown.

Josh Birk:
Right. Right.

Daniel Ballinger:
And then, it’s going to land in the middle of a forest or in the middle of the ocean or something. And then trying to marshall the resources to go and get it. Or if I get into trouble like, “Oh, I’m stuck up a tree in the middle of a forest, come rescue me.”

Josh Birk:
Mm-hmm (affirmative). Yeah.

Daniel Ballinger:
But it’s an interesting challenge. It’s something I’d still like to get around, but then when you actually go through it, it starts to get quite complicated. Because airplanes that fly at that height don’t typically like to encounter things just randomly floating up towards space. So, you’ve got to work with the Civil Aviation Authority, you’ve got to work with air traffic control, and you can tell where it is. It’s still a quite dream, I mean, to just be able to say I sent something to the edge of the space.

Josh Birk:
Right. Right. Yeah. And just to clarify, for those who didn’t catch the first episode, we’re not talking about launching Astro into space with a lot of rocket fuel. You were going to actually get a weather balloon, correct?

Daniel Ballinger:
Yes. The weather balloon, and then fill it with helium. Well, hydrogen would be cheaper, but there’s the whole combustible problem.

Josh Birk:
Boom.

Daniel Ballinger:
So, yeah. Fill it with helium, strap an Astro to the outside, and then get some telemetry back, was always the intention.

Josh Birk:
Gotcha. But now, you are the relatively new Apex Product Manager. How did that come to be?

Daniel Ballinger:
So, a similar story to what Chris had, where he had opinions, a lot of opinions about how Apex should be transitioning in the future. And he cared a lot about it. And then I’m sort of the same. Although I think somewhere in his story, he had a Highlander reference that he chased the old PM out. I haven’t chased Chris out. He’s still there, thankfully.

Josh Birk:
Nice. Nice.

Daniel Ballinger:
It’s more of a collaborative effort there. But yeah, I’ll take over the Apex dedicated part of it. And he’ll sit over the language services as a whole, so more integrated with Heroku as well.

Josh Birk:
Gotcha. What are some of your early interactions that kind of got you into this position? What level of detail … Was he in your brain before you took this role about what Apex should and shouldn’t do?

Daniel Ballinger:
I’ve always had opinions. I mean, they go way back. Things like how do you enforce the security model, which is topical for them, things we’re currently working on. How do you do debug logging, what’s the implication if you turn debug logging on, how do you run tests? That’s always been a popular one. I mean, obviously that’s an important one for developers, is your testing cycle defines how fast you can move. And that’s another area we want to focus on in the future. And then I’ve had more in depth, technical ones through security implications of certain features. That’s one of those you don’t talk about, security features. You don’t talk about security club.

Josh Birk:
Right. Right. Exactly.

Daniel Ballinger:
Yeah.

Josh Birk:
So, going to ask you the same thing I ask all product managers. How would you describe your job?

Daniel Ballinger:
Mm. Balancing, a lot of balancing. A lot of weighing up what’s the implication of, if we tackle this now or tackle it later, what’s going to happen if we don’t address a problem as it’s coming up. And then, balancing that against the other issues or features we might want to be addressing. So, if there’s something relatively easy we can do, which will have a large impact on benefiting developers or the system stability, that’s certainly something we’d look at doing earlier. But then, if it’s going to be a massive effort for not much payoff, then the balance sort of swings away from that one.

Josh Birk:
Mm-hmm (affirmative). How easy do you think it is to go fast and not break things at Salesforce?

Daniel Ballinger:
That’s a tough one. Like, if you’d said that early on in Apex or Salesforce career, it would probably be easier. But now we are processing hundreds of billions of transactions a month with Apex. And so, small changes can have very large impacts. And you think about edge cases, and you think, “Oh, well, what’s the edge case on this? Well, what’s the edge case when you multiply it by hundreds of billions?” And then all of a sudden, that might be affecting more users than there are in the country I am currently occupying.

Josh Birk:
Right.

Daniel Ballinger:
Yeah, I think … We work in the many million, yeah. Millions? Billions of users. It’s like, “Hmm. Millions of users,” and there’s more people there than there are in my country.

Josh Birk:
So, the definition of breaking things is actually pretty broad on that scale. Like, even just slowing things down inappropriately would be considered breaking something.

Daniel Ballinger:
Yes. Yeah, and that’s actually something I didn’t realize from the outside coming in. But now that I’m on the inside, I realize Apex engineering puts a lot of effort into the scalability and growth of the system. And when they do that well, you don’t actually realize from the outside that it’s happening, because it doesn’t go in the release notes. It just happens transparently. And that growth keeps going. And I realize that’s something that we actually spend a lot of our effort in, and that’s something as a product manager, we have to balance with the features, is making sure the scalability and the growth and the performance is still there for everyone, and making it transparent.

Josh Birk:
Yeah. It kind of reminds me of all the game updates I get, which just simply say performance enhancements and increased speed on things, but doesn’t actually tell you all the things that they actually fixed.

Daniel Ballinger:
Yeah. I think a lot of the things we actually fix never even go in the release notes. And when we do our job well, nobody knows. Or, you might get one or two edge cases. Hopefully they’re not the ones of the larger side of the billion. They’ll be in the teens, which is success. And great success, really.

Josh Birk:
Nice. Nice. So, I think I asked Chris this question. And to turn that around to the users a little bit, are there things that Apex developers could do to make your job easier?

Daniel Ballinger:
Oh, would I be repeating what Chris said if I said make realistic or useful unit tests that actually exercise your code and make meaningful assertions. I mean, obviously that helps you, but it helps us help you, because that’s part of the hammer cycle, as we will run your tests and ensure that we are not regressing things. So, we can say more confidently that the changes we’re putting out aren’t going to cause edge cases or problems. And then, there are cases where customers will say, “We’ve written our code, we’ve got to the edge of the Apex character limit. Can we please have a bit of an extension on that?” And at that point we have to go to their code and say, “Okay, are you helping us help you? Are you writing good test cases for your code, so that we know when we give you more that you are not going to run into problems?”

Daniel Ballinger:
And that’s usually where we come into the odd person who said, “Ah, i++.” I can just write a giant method, and 80% of my class will be this one method that says i++, and we have to turn around and say, “No, we can’t. You’ve padded so much percentage of your usage with something that helps nobody.”

Josh Birk:
Right.

Daniel Ballinger:
“You need to fix that.” And it would make my life a lot easier if nobody went for code coverage hacks. I think there was even a … I don’t know. Is this family safe? We’ll do the family safe versions, where somebody Base64 encoded an image and then put that Base64 encoding into the method.

Josh Birk:
Oh gosh.

Daniel Ballinger:
And then they used that to push their code coverage up by just running that method. I won’t tell you what the image was when you decoded it, because we’re family safe.

Josh Birk:
Okay.

Daniel Ballinger:
It was like, very creative.

Josh Birk:
Wow.

Daniel Ballinger:
And the reason it came to us is that actually caused them heap issues, and so they hurt themselves more than they hurt anybody else.

Josh Birk:
Right. Right.

Daniel Ballinger:
But, you’re creative. To help you, please do write proper test cases.

Josh Birk:
Right. Points for creativity, no other points.

Daniel Ballinger:
Yeah. You’re minus 10 points for Gryffindor or something for breaking your own heap limit.

Josh Birk:
Yeah. Yeah. So, it has come up in conversations in the past, and I think I know what the answer is, because the answer is still true. But, that particular hack, the i++ hack, is so heated, it has come up so many times on the pod. And it’s like, have we considered being more forceful about detecting that code and telling people to knock it off in some way, like a warning or an error or some flag when they run their unit test, or anything like that?

Daniel Ballinger:
I have thought of that. There’s some interesting concepts around some of the other products we’re doing actually related to data weave, which is something we could come back to later, where we could … I mean, this is all very forward-looking type statements, but we could bring in more code quality checking tools into the system. And then that would help when people say, “I need some more, can I have my limit extended on my character limit?” And I can say, “Well, the metrics will say your code is done to quite a high quality.” And if we can scan and enforce that automatically, that would make everybody’s job easier. Because they’d naturally know the quality of the code they’re producing. Well, measuring code quality is always a difficult thing to do with metrics.

Josh Birk:
Right.

Daniel Ballinger:
Like, you start saying cyclomatic complexity and things like that. And they have their place.

Josh Birk:
Yes. Yeah. A phrase I had never heard before until I started talking to Robert, so it’s been about the static code analysis and stuff like that.

Daniel Ballinger:
But, you could imagine if we start running static code analysis on deployments or within the [crosstalk 00:15:02] on a regular basis, and we could start [crosstalk 00:15:05] … I mean, that’s all sort of what if-type concepts at the moment, things we’ve been thinking about.

Josh Birk:
So, you mentioned DataWeave. Let’s talk about that a little bit. First of all, let’s level set. What exactly is DataWeave?

Daniel Ballinger:
DataWeave is a component of MuleSoft. It’s their data transformation language. So, it might say, “I have a file in this format, and I want it to come in this format.” And it’s … I don’t want to say declarative, or … It’s very domain specific, and it’s very concise. They might say it’s declarative. But I’d say, “I want this input, and I want this output.” And you figure out exactly how to do it. It’s mostly my … And it’s very powerful, and it’s very specific to that task. It has a lot of data manipulation, short commands you can give it. So, very powerful in that sense. And so, from Apex’ perspective, we’ve been working with the people from MuleSoft on the data we product. And we’ve been able to bring that as a pilot inside Apex. So, a common thing from Apex is, I’ve got a CSV file, I need it as objects or as adjacent file.

Daniel Ballinger:
And do you think … CSV is the simplest format in the world, right? It’s a comma, and it’s some data and a new line. But then when you actually get into the spec, it’s like … And I’ve tried to do this in Apex. You start to get escape “characters” and new line characters within lines. And it actually becomes really hard to break that data down in Apex. But with something like DataWeave, you can say, “Here is my CSV file, I would really like that as adjacent, please.” And it’s a couple of lines of DataWeave script. You pass it in, you get what you [inaudible 00:16:58], and you can carry on solving the interesting problem. I don’t know many people who say, “I really would like to write my own CSV parser.” They’re more interested in solving the problem and writing.

Josh Birk:
Right.

Daniel Ballinger:
And it’s like one of those cases, “I’d really like you to write less Apex code parsing CSV files, and more solving the interesting problem,” because then you then have less to test.

Josh Birk:
Right. Yeah. Yeah. I’m not even sure I’m a fan of the phrase, “I want to use a CSV parser.” The less lines of code that I want to worry about, especially the things you’re talking about. I mean, those are almost universal things every coder has ever run into. Like, “I thought I caught that new line. But oh, it’s not that new line character in whatever CSV file I pulled from, random database acts” kind of thing. So, is it one to one? Is the language the same as what MuleSoft uses?

Daniel Ballinger:
Yes. It’s the DataWeave 2.0 scripts.

Josh Birk:
Okay.

Daniel Ballinger:
There are some limitations around what you can’t do. There are some parts of DataWeave scripts that aren’t suitable for use in a multitenant environment. We don’t want you jumping off into the file system, so things like that are blocked. You can’t pull those in. But in terms of the raw input and processing, most of that is there.

Josh Birk:
Okay.

Daniel Ballinger:
And then the interesting part is, it’s actually part of your transaction, your Apex transaction. So, it’s within your sandbox or your … So, things like limits and heat on CPU are still enforced. But of course, because DataWeave is much more focused on solving that problem, they can do it with far less resources than you could ever do with Apex, unless it’s a trivial example. But certainly, the complexity scales, they’re better suited for solving those types of problems.

Josh Birk:
Okay. So you said MuleSoft, and I’m a big fan of MuleSoft, but does this mean if I’m going to use DataWeave, that I need a MuleSoft license?

Daniel Ballinger:
Not for this feature from Apex. So, if you wanted to use DataWeave from Apex, it will all be built in. It’s not a separate skew that you need to go to your [inaudible 00:19:06]. It’s just something, once it’s out of pilot, you’ll be able to just use it as part of your normal Apex routines.

Josh Birk:
What’s a good example of just how big that gap could be? Like, if I was trying to do a CSV to adjacent operation in Apex without DataWeave versus I have DataWeave, it’s far less lines of code, right? Because DataWeave can do that, I think, literally in three lines. How much of a saving is it, like in heat and CPU size?

Daniel Ballinger:
I should get at those exact metrics. But I know from historic-

Josh Birk:
Yeah, you could ballpark.

Daniel Ballinger:
Yeah. So, from my previous experience, I remember having CSV files that start to run into the few thousands of lines, starting parse problems. Whereas something like that, once it’s converted into a format that Apex can process more directly, the usage drops significantly. Now, I mean, we’re still in pilot, so there’s also these caveats.

Josh Birk:
Right.

Daniel Ballinger:
A DataWeave script needs to be compiled, and that’s actually part of your transaction cycle.

Josh Birk:
Okay.

Daniel Ballinger:
So, you pay a small upfront cost, but then get a bigger benefit in the amount that you could actually process. But of course, all this is sort of in flux at the moment as we work through the pilot.

Josh Birk:
Got it. What does that look like? Like, how do I hand that script off to Apex pilot, where can I place files like the CSV that I’m sourcing from? What are my options there?

Daniel Ballinger:
Currently, the DataWeave scripts are deployed to the .org as a metadata file. And that’s quite nice, because on deployment, it will do a compilation to make sure you’ve got valid syntax. But then within the actual transaction, you reference that script by name of the metadata file. And then you can pass it on execution along with the payload. And it’s interesting, because DataWeave scripts can have one or more inputs. So, I’ve actually done an example where I brought three different files, and used DataWeave to combine them into a single file. Currently, the output is a string, but we are working through the pilot again on options to expand that. Obviously, it would be nice to be able to get direct objects back into Apex so that you don’t need to do additional processing.

Josh Birk:
Right. Right. Can I pull a CSV file remotely somewhere?

Daniel Ballinger:
Currently, the input has to come direct from the Apex. So again, and this is part of the sandboxing of DataWeave, is we don’t want it jumping outside the boundaries of the transaction.

Josh Birk:
Gotcha. Okay, so it’s a pilot. What is the roadmap for accessing this look like for developers?

Daniel Ballinger:
We’re sort of running two pilots in leapfrog. There’s the user mode database operations one, and then the DataWeave one. And so, we’ll run one in pilot, and then the other, and then we’ll move them both towards developer preview in the following releases. We also have to take time, like if something comes up during the pilot, we might have to push that roadmap out. And that one of the other things you realize when you come inside, it’s like the transition between pilot to beta to GA. And what happens if we need to do extra development cycles in between?

Josh Birk:
Mm-hmm (affirmative). Yeah. The always, that gilded cage of before anything can go to production, make sure we’re not actually breaking anything. Or that you want to change things

Daniel Ballinger:
Well, that’s it. Once it starts to become part of that hundred billion transactions, I want to know we’re not going to have to make significant changes, because breaking things is not something we really want to be going down that path.

Josh Birk:
Right. Or even just changing implementation. Like, yeah. No developer wants to have to make sure that they switch their method because we did an API update or anything.

Daniel Ballinger:
Yeah. Correct. Yeah.

Josh Birk:
So, okay. So, let’s move on to this one that you just mentioned. Describe user mode database operations to me.

Daniel Ballinger:
So, standard Apex runs in what you might think of more like a system mode, and that is, it won’t enforce object or field level security for you by default. And then, that makes sense for a lot of use cases. Say you are a ticketing system or something, and you want a user on your website for your community to come in and say, “I want to buy this ticket.” Well, the user themselves probably wouldn’t have permission to create a ticket, that’s not something that they can do. But as Apex, that system can elevate and say, “I can do that for you. I’ll make the ticket. I will assign the field values that you don’t have access to and then return the record ID back.” So, that’s sort of why system mode for an elevated business process makes sense. The code should have access to do things they couldn’t.

Daniel Ballinger:
But then, the flip side is, a lot of business processes want to respect the rights or the access levels that the current executing user has. And that’s where system mode comes in. We have a number of tools that range in complexity from very simple to more robust. So, at the simple end on the cycle statement, you could just say with security enforced, and that will enforce what the level of access that user has. But, it doesn’t provide much flexibility if the system needs to adapt. And so, you can swing it all the way around to the other end, which is the describe [inaudible 00:24:52] where, in your code, you could drill down to each individual object in each individual field and find out exactly what level of access that user has.

Josh Birk:
Right.

Daniel Ballinger:
And that’s super flexible, but also it puts a lot of onus on the Apex developer to make sure they’re enforcing all those things. And if they make a change, they have to go through and check everything.

Josh Birk:
Right. Right.

Daniel Ballinger:
The user mode, a database operations pilot, sort of a reverse thought of that and says, “What if we just enforce that at Apex level and then cave back any metadata, or gave back any data that says why we failed to do it.” So, it’s basically secure by default. And then if you want to take more control from Apex, you could do that through system mode.

Josh Birk:
Gotcha. What does this look like in line, in the code itself? Like, how do you switch between safe mode and system mode?

Daniel Ballinger:
Currently in the pilot, there’s an extra parameter you’d pass to most DML operations to basically say, “Do I want user mode or system mode?” And the nice thing is, that it is parameterized so that you can take the level of control you need in the code based on scenario or the business process you’re trying to solve. Longer term, and this like forward looking-

Josh Birk:
Forward-looking safe harbor.

Daniel Ballinger:
Yeah.

Josh Birk:
I swear, I should just title my product manager episodes like, “Safe Harbor with Daniel Ballinger”.

Daniel Ballinger:
Yeah, yeah. Yeah. Yeah, looking in that direction, we’re looking to how we could make transactions secure by default and then opt into system mode. And that would be hugely beneficial for most cases, as you don’t even need to think about, “Does my current user have that level of access?” It will just force it. And then if you say, “Oh, actually, I really need access to create a ticket for the ticketing system that the user wouldn’t otherwise have permission to, and I’ll know I’ll need system mode there to get that elevated permission.”

Josh Birk:
So, would that be a class level annotation?

Daniel Ballinger:
It would probably be-

Josh Birk:
In the future.

Daniel Ballinger:
It would probably be more fine-grained than that.

Josh Birk:
Okay. Okay.

Daniel Ballinger:
So, everything would default … I think, because you don’t want to make … With sharing and without sharing is an interesting one. That’s kind of where you do class level. And then to reason about that starts to get really difficult. So, we’re aiming to look for something more accurate or more succinct. And then you could look at it at a pure statement level.

Josh Birk:
Got it. So, it’s a little bit more-

Daniel Ballinger:
So, you wouldn’t have to be at the statement and then jumping up to the class and say-

Josh Birk:
Right.

Daniel Ballinger:
What class called me, and what permission were they, and then it starts to get quite hard to reason about.

Josh Birk:
Gotcha. So something more on a language-wide level, and you aren’t really worried about the class structure itself.

Daniel Ballinger:
Correct, yes.

Josh Birk:
Got it. And, I feel like this is just an important topic, because it’s like, if developers don’t keep this in mind, even with this great new future you’re building, they can really run into trouble, because they can give users access to things that the user is not really supposed to have.

Daniel Ballinger:
Yes. Yeah, it is a bit of a danger. And it’s like, who should be thinking about security, is the question.

Josh Birk:
Right.

Daniel Ballinger:
The reality is, everybody should be thinking about security. And you might not want to think about it, but it will make itself known to you one way or another that you should be thinking about it.

Josh Birk:
Right. Yeah, I’m trying to remember the interview, but the line was something along the lines of, “You want to think about security before your client does,” basically. Like, before your customer starts having to pick up the phone about it.

Daniel Ballinger:
Hmm. And then that’s another nice advantage if we move to secure by default, you would have to think about it because you wouldn’t be able to perform the operation otherwise. If you didn’t meet the security model that you’ve otherwise asked for.

Josh Birk:
Right. Right. But that still feels like a pretty elegant solution, because instead of trying to think on a field level and a transactional level, the developer gets to think about it from an application design level. Like, “I’m doing all this stuff, oh, now I have to go into system mode to do all the super stuff and then get back out of system mode because I don’t need it anymore.”

Daniel Ballinger:
Hmm. And then when you’re thinking, “Oh, I’m in system mode. Hang on, there should be alarm bells going off in your head.” It’s like, “What am I actually asking for access to?”

Josh Birk:
Right.

Daniel Ballinger:
Hopefully they would be more cognizant of what they’re asking it to do.

Josh Birk:
Yeah. Yeah. What does a timeline look like for these things, for DataWeave and user mode database operations?

Daniel Ballinger:
So, yeah. So, both piloting are around about the same time, sort of leapfrogging between releases with each other.

Josh Birk:
Gotcha.

Daniel Ballinger:
Depending on the output of those, assuming those pilots go well and we’ve got our interfaces reasonably clean so that people can start implementing against them, we’ll be looking at doing the GA in the following releases.

Josh Birk:
Okay.

Daniel Ballinger:
I’m sorry. Not GA. I should say. Beta. We don’t go straight from [crosstalk 00:30:04]. We want to make it a much more wider developer preview.

Josh Birk:
I could use it in developer edition or sandbox or something like that, but not deploy. Yeah, got it.

Daniel Ballinger:
Yeah.

Josh Birk:
Got it. So, speaking of roadmap in general, are there any future updates to Apex that you are willing to talk about? And once again, safe harbor for working statement, et cetera, et cetera.

Daniel Ballinger:
Depending on when this podcast comes out, I haven’t figured that one out, there’s the interface implemented discovery, which should be a nice one, especially for ISVs. So, what that will do is, it gives you a mechanism so you can find classes within the org that implement a particular interface. So, if you’re in ISV, you might publish an interface and then your subscribers of your package could implement that interface. And then this will give you a mechanism to find the classes that they’ve used, that they’ve customized based on your package. So, it’s really good for like a plugin architecture, because previously they would have had to communicate back to your package which classes implemented your interfaces. So, yeah. It allows for a lot more customization or interaction between the package and the subscriber.

Josh Birk:
Okay. Okay. Any other fine tuning things that you’ll be able to see in the language?

Daniel Ballinger:
I mean, there’s lots of really fine grain fixes we are making, or will be making. Things like tweaks to the switch statement, constants. But there’s larger, more broad sweeping things which don’t have specific details, like improving the performance of test cases.

Josh Birk:
Gotcha.

Daniel Ballinger:
Again, it comes back to that turnaround time of how long does it take for me to run my tests end to end.

Josh Birk:
Right. Right.

Daniel Ballinger:
And get the results. But, that’s not something where we can just make one small tweak and everything will instantly go faster. There’s a number of things that will go into that, which makes it a longer term roadmap.

Josh Birk:
And that’s our show. Now, before we go, I did ask after Daniel’s favorite non-technical hobby, and like many of my guests, he had, well, not just one, but a couple of interesting ones.

Daniel Ballinger:
During lockdown, I took up running as a hobby.

Josh Birk:
Nice.

Daniel Ballinger:
I mean, there was just this way to get out. But recently, I sort of got enamored. I was watching YouTube videos of people doing wing foiling. Have you seen that? It’s where they have an inflatable kite that they hold, and they go out on a board and it has a foil and it lifts them up and pulls them on. Now admittedly, I’ve never done that. So, maybe I’m being a bit ambitious thinking I could. But, I’ve subscribed to do some lessons for that. So, that will be an interesting thing.

Josh Birk:
Nice. You find the most interesting sports, because you’re also into, is it kayak polo?

Daniel Ballinger:
Yeah, I do canoe polo.

Josh Birk:
Canoe polo.

Daniel Ballinger:
Quadcopter racing. Yeah, some of these things sort of go together, kind of. Yeah.

Josh Birk:
I want to thank Daniel 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 develop.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again, everybody. And I’ll talk to you next week.

Show Highlights:

Links:

Episode Transcript