Chris Peterson, who joins to talk about Apex language, is the Director of Product Management for Apex in Salesforce.
Sponsors
This episode is sponsored by FormAssembly.
FormAssembly and Salesforce eBook – Find out how FormAssembly helps Salesforce customers optimize their data collection.
This episode is sponsored by Clayton.
Go to Clayton website, request a demo or use the chat service by telling “salesforceway” code to receive free one month Secure Development Essentials.
Main Points
- What is the responsibility of Chris’ team?
- How does Chris and the team collect working items?
- Is the idea exchange a good channel for developers to submit wishes?
- How does the team implement, test, rollback new features? The internal hammer tool
- We talk about the story before and after the new Apex compiler, and what new features the new compiler brings to developers.
- What is the language server and how does it support LWC and Apex?
- Is a local Apex compiler viable?
- What is the new evergreen platform and how does it work in principle?
- Why does Chris think the evergreen platform is also good for Apex?
Links
Video Teaser on Apex Language
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:01] I'd like to welcome our sponsor, Form Assembly. Form Assembly's all-in-one web form platform lets you create forms for just about any use case. From contact forms to donation forms, all while taking advantage of useful features such as notifications, e-signatures, and more. Not only that, but you can also connect data to systems you already use. FormAssembly integrates with Salesforce, PowerDart, PayPal, and many other common solutions. You can find out how form assemblies help Salesforce customers optimize their data collection in a free ebook that we've linked in today's show notes. Whatever your data collection needs are, you can be sure that Form Assembly keeps your data secure with encryption at rest and in transit on all plans, plus compliance with GDPR, CCPA, and more regulations. At the end of the day, Form Assembly helps you save time, money, and effort while getting the maximum benefit out of the data you collect. And I'd remind you, when you support our sponsors, you support the show.
[01:21] Chris, Chris, you're going to tell me it works this time, right? Yeah, now it works. I don't know when I hit the start recording button, does it still work or not? That's the that's the point. But if your browser can break Skype, I am impressed. I have no idea why, but at least I think the browser and the Skype is used in the same model input. I'm trying to do that. Yeah, but the same on mine. Yeah, but I don't know. Let let me hit the start recording. Just yep. Can you still hear me? I can still hear you. Okay, I can still hear you. It's a miracle. It's a miracle.
[02:13] Hey everybody! This is Xi Xiao. This is yet another new Salesforce Way podcast episode today. I'm sitting with a guest with me. His name's Chris Peterson. Hello, Chris. Howdy. How's it going? I'm good. I'm good. Everything fine. How about you? Mildly annoyed by audio difficulties before we started, but otherwise I'm great. Yeah, we had some technical issues, but everything's fine now. So Chris, would you mind to introduce yourself before we start? Yeah, sure. So I am the director of product management for Apex at Salesforce. Before that, I was a lead engineer on the AppExchange engineering team, and before that, I was an architect at Financial Force. So been working in the Salesforce ecosystem for quite a while at this point. Ah, I know Andy Faucet was also coming from Financial Force. So you were okay. You were working the same company before. I didn't know that. Yeah. So since you bring that up, I actually just started reporting to Andy a few weeks ago. So, okay, it's it's a little bit interesting because we work together really closely at Financial Force, but I never reported to him. So I constantly get the question of, "Oh, so you're reporting to Andy again?" And then I have to explain that no he he did technical leadership instead of people management at Financial Force, which is why he wrote so many good blog posts, so much open source code, etc. And this is my first time reporting to him officially, but not my first time getting into a technical debate with him. Ah, because the last time I met him, he told me he was the platform
[03:44] product manager. That's like Lightning Platform, right? But Apex belongs to the Lightning Platform. Or yeah, the the specific terminology as you've noticed may change as there are different rebrandings. Yeah, yes. So up until a few weeks ago, I was officially part of Lightning Platform, the group inside of Salesforce. But then Andy and part of Wade's group now, Wade Wagner as well, is the platform developer services group. So there's a new charter specifically for. Programmatic languages on the platform, which obviously is Evergreen Functions and Apex. So, we got moved around in that reorganization, so that now I'm I'm with Andy's team. Evergreen Functions also rolls up to him, so. The platform programmatic services are now all in one product group. I see, but for your own responsibility, is still in the scope of Apex only, right? Yeah, my job description in the last two years has not changed; it's been Apex the whole time. Yeah, so yeah, I. Nothing materially changes except two signs off in my expense reports, and that I will be in more meetings about functions, which is probably a good thing. Okay, how many people do you have in your team? So Apex is.
[05:12] Rather than give you a specific number so that somebody can beat me up if it changes again, I'll say that Apex is generally in the ten to fifteen range in terms of engineers. Depends on when you ask and what form of the team and what the specific mandate and charter is at the time. It was a little bit bigger during the new compiler project. It shrunk briefly for a little while when a couple people left, and we were. Didn't want to hold on to headcount that we couldn't fill right away, and then those kind of got reallocated later. But in the neighborhood of ten to fifteen, depending on when you ask, yes. Okay. So could you also give us the brief introduction, like what things your team routinely do? We know we have these three releases per year, so I think your team's task is allocated to those three releases. And there's also weekly releases that have a lot of bug fixes in them. So it depends on what type of issue you're hitting. So we we do almost always have something in one of the weekly patch releases, although it's usually not something that you'll notice. But fixing a gap that popped up in in enough customers that it looked like it was fairly seriously impacting their operations. If there's no technical risk to it, then that's something we do in a weekly patch. If it's making a more fundamental change to the language or the behavior of the standard library, then that's definitely something where almost always we end up having to wait for a major release. And usually, even if we're fixing bugs in the standard library, we'll version those fixes. So. To get the bug fixes in,
[06:43] describe for example, you would have to upgrade to the Summer '20 version if we fixed a bug in Summer '20. Because what we've discovered is that people will actually rely on the bugs in the language. So if we fix them retroactively, it breaks existing code. Yeah, I know that it happened. How does your team actually collect the requirements, the the items put into each releases? Good question. A lot of it comes from customer feedback. You know, I hear a lot about how the language needs to be expressive more. That's something that's come up a lot on Twitter. People asking for generics and online dinner classes. So that type of customer feedback is definitely something we try and prioritize. So you mentioned Twitter. Twitter is also a channel for you to collect the feedbacks. Yeah, a huge one because okay, Apex is fairly interesting in that pretty much everybody uses it. There is like I think the latest number is like over two hundred thousand orgs run Apex that are paying customers, not not including developer editions. So okay. We're looking at something that almost everybody uses, and so the breadth of people who send who have opinions on it and feedback is more than I would get through sales engineering. I would hear about new customers, especially larger ones, that were what they were interested in through that channel. I'll hear about what people think is broken through support. I'll hear some feedback on the partner community about specific performance issues that affect partners
[08:13] more than enterprise customers. Um. But all of those channels of feedback really have some type of constraint or a target audience that they're not effective necessarily getting all types of unfiltered feedback. Staff level engineers at an enterprise customer that didn't get an executive to carry the torch on their little tiny feature that would improve quality of life. We want to make sure we catch those, and something that's a little bit more accessible has helped with that. And a lot of it also stems from when I was a customer and a partner, I used to engage with the Apex team on Twitter all the time. So kudos to Josh Kaplan, Rich Unger, Greg Fee, who all used to work on Apex and all were really responsive and really taught me the value and. How much of a difference it can make to a customer when you have that type of open communication channel? And now that I'm in their positions, it only feels fair to keep the tradition alive. Thanks for that. I'm also a Twitter user. I know how active you are there to listen to the users. How about the the voting website in the Trailblazer community? The Idea Exchange. Is it? Yeah, I think it's idea exchange because people say that developers are minorities, so we don't get enough voting numbers. Is that a concern? Yes and no. I think that actually impacts partners more than it does for enterprise customers because so there's the new idea exchange with the the comparative ranking and
[09:43] that went to market. Specifically targeting end users, they do have some longer term plans on targeting developers that I've talked to them about, but they're still a little bit hazy at the moment. So the new Idea Exchange, I don't personally get a ton of feedback from. There are a few developer centric features that that end up there, but it's it's not targeting the pro code audience today. And that that's fine. So the traditional idea exchange, which I think is more what you're referring to, without the comparative ranking, but just with traditional voting.
[10:16] I do go through that usually once a release, and look for ideas that are that make sense. And the number of votes kind of helps justify a relative position on the roadmap. But if it's the right thing to do, it's the right thing to do,
[10:32] So it's one of many weighting factors. Have I heard about that this is a problem from other customers? Have I heard that this comes this come came up at meet the developers at Dreamforce? Did somebody tweet at me? Did somebody email me? Have I heard from an account executive or sales engineer or support engineer? And so the votes are one factor, but really it's. It's more likely, more likely that I have like a quality of life bucket in each release, and especially on a lot of those smaller ideas that that tend to be quality of life rather than game changing ideas. We pick the ones that we think will be the most impactful. And votes can sway our opinion on what's the most impactful, but it's not like we're sitting in front of a report of what has the most votes. This is what we're doing this release. There's, I understand. There's multiple humans in the loop. Otherwise, that process would be interesting. Yeah, yeah, I know. Then how does the team really to implement, you know, test release these things, and even sometimes we do need to roll back in case something bad happens. So could you walk us through this process? Yeah, you probably heard about Hammer at some point in the past. Yes, that's one of the Developer Podcast episodes talking about that. Yep, talking to Rupa, who used to be on the Hammer team, so Hammer is something that we spend quite a lot of time working with as a final check that nothing's going to break in Apex. It obviously can't cover a hundred percent of things. It can't cover user interface interactions. Some of the community site changes,
[12:02] because hammer tests aren't run in a community context. There's an Apex test that can pretend, but isn't always a hundred percent. Hammer isn't a one hundred percent guarantee that that nothing is wrong. But it is a very very important process in catching tiny little mistakes that otherwise could ship and impact people. What we usually find is an uncovered edge case or something like that in Hammer, and that is really the the end of the release. So internally, we have feature freeze where you stop working on feature work and work on stabilizing the release. Hammer picks up the changes. Basically, the day after feature freeze, and then runs with those, and then we have a couple weeks to triage the results before the actual release freeze and before it starts going live on GS zero and pre releases. So, for the Apex team, really between feature freeze and release freeze is. Majority hammer triage. We look at all of the hammer diffs, and there is some machine learning post processing that goes on that cuts down on the volume of noise. But usually, a human looks at each one of those and. We have a discussion about if it's intentional, if it's expected, if there was some sort of metadata change in the org that happened while Hammer was running that might have offset the results. But usually, there's three, four, five, six actionable bugs that come out of it. And you know some of those would be very painful to fix after the release went out. As we were just talking about,
[13:33] people start to rely on bugs, and if we start making changes in the runtime or the standard library without a new major version to go along with it, that could break somebody else. So. There's peril in fixing bugs too aggressively, which is really one of the places that I love Hammer the most. Okay, for the people who don't know Hammer, it's a tool only for Salesforce internal teams to use, right? External cannot really use that. Not not at the moment. There are some some open ideas around that about making it available for ISV partners, but nothing I can announce or talk about at the moment. Okay. Okay. Yeah, Hammer is run internally. What what happens is one of the replicas of. Yeah, the the secondary data centers backup is upgraded to the new release after it's disconnected from the internet, so it can't actually make changes to anything for real. So it's upgraded to the new release, and the tests are run on. Against the old release and the new release, but basically with the same state otherwise, and then the diffs are compared. So if you have a test that fails beforehand, but fails differently after, we actually get a hammer bug for that. So if your tests are failing, they should continue to fail the same way. If your tests are passing and they start failing, that's a problem. Okay. If your tests are failing and they start passing, that's also a problem. Yeah, it's the state. You always need to compare, right? Yeah, but it runs across effectively every customer
[15:03] org, all paying orgs, with a handful of very limited exceptions. Whenever there's Specific challenges, but effectively it runs against all paying customer orgs, all tests, and so it runs millions and millions and millions of tests, and that gives us a huge amount of confidence in the release and feedback about customer impact that we otherwise wouldn't have. I understand. In 2018, we had this new Apex compiler. Yes, was it a huge news? To me, that's the moment I joined Salesforce. I had no idea there was a new compiler until yesterday. Somebody told me. I was asking, "Do you think it is some good question to ask Chris?" They said, "Why not the Apex compiler?" I said, "What is that?" So I actually joined the Apex team right at the end of that project. So I basically got to walk in and go, "All right, turn it on." Well, that was easy. I don't know what the big deal was, and then everybody threw things at me because they spent four years working on the new compiler. So I get to take all the credit and did none of the work, which is always the best place to be. Okay, but the Apex compiler. So Apex started out as a pure runtime interpreted language back in 2006 when it was created. That had a number of issues. With, there was no capability in the language for anything reflective, which meant that things like JSON deserialized where you pass it a type token just were inherently not supported. Because it it was so limited in terms of the runtime, it also meant that
[16:33] there was a really a large amount of heap overhead as the language ran, and so I think it was 2012 or something like that. It was like before I worked at Salesforce, but. Back in that day, that era, there was an increase in the Apex heap size from three to six megabytes, and that was when Apex went from a pure runtime interpreted language to a compiled language that has some runtime interpreter for injected attributes, and so that was the first time that Apex really evolved materially as a language in terms of runtime and compiler. But that project was done to keep full compatibility, including any sort of behavior quirks and bugs. And when you're trying to, I think Dan Appelman said, replace the engine on a jet while it's in the air. There's always constraints on what you can do, and you aren't always entirely happy with the way the product, the end product, turns out from a maintainability perspective.
[17:32] It was also just inherently coupled to our codebase in the core platform. It could not be extracted. It could not be run off the platform, even in any sort of limited capacity. It was joined at the hip and just had its tentacles everywhere, which made sense at the time. But when the newer development tool strategy started of language servers. That meant that there was going to be no Apex support. That would mean no VS Code support for auto completion. That would mean no PMD tooling. Oh, and so one of the the big justifications, one of definitely not the only, for rewriting the Apex compiler was to make it something that was a standalone compiler, so that a proper language server could be built and distributed. And so the when you run Visual Studio Code with all the Salesforce and DX extensions, it's actually running the Apex compiler as part of the language server locally. It's not doing anything with the bytecode because you're still missing our runtime. But all of the code completion and validation is using the real actual compiler. Hmm, I understand language server was the idea coming from Microsoft, wasn't it? It's their it's their open standard, yeah. Yeah, and the Visual Studio Code started to use that and then get it very popular. So what what is this language server for Apex, especially? So the language server is just a an open protocol for Building pluggable modules for different languages that aren't directly embedded into an IDE or other tooling. Okay, and so it's
[19:02] a protocol for talking to something that provides information about the language, refactoring, syntax checking, all kinds of error information, auto completion, and so it's it's a standard API for that. A compiler in the cloud. You are talking to the cloud to get the information back. No, it runs locally, so the the language server and Visual Studio Code both run on your computer. But but it's a open standard, so the language servers are pluggable. So when they made Lightning Web Components, they also introduced a language server for that. And so Visual Studio Code doesn't inherently have Apex and LWC support, but because it's an open standard for language servers that Visual Studio Code understands, plugging in an Apex and LWC language server means that you get that type of functionality in it. Okay. So the the old style was like textmate language bundles if you wanted to add syntax support to a new tool. But that was really limited to just syntax. You couldn't do refactoring suggestions. You couldn't do any deeper introspection, and the language server protocol added a lot more capability on top of that model of. Extensible language support, but in a standardized and more powerful way. Okay, and like Nate Totten would actually be a person to talk to for a lot more detail because I haven't spent as much time with like the language server protocols I'd like. So, yeah, Nate Totten's group actually owns most of that. I am just, I am parroting what I've learned along the way. Yeah, I
[20:33] know he's really active collecting the Visual Studio Code plugin feedback as well in the Twitter. Yeah, yeah. So his team owns the the language server wrapper around the Apex compiler. So my team has internally it's a Git repo that they then take along with a bunch of dependencies, package up into a single self-contained jar file, and added the language server. API compatibility on top of it, so they built a wrapper bridge compatibility layer between the Apex compiler and the language server spec. This episode sponsored by Clayden. If you build on Salesforce, you know writing secure code can be really hard. Claden makes it easy for you. Claden plugs into your Git repos in seconds and automatically protects you from hundreds of security vulnerabilities, such as Crowd FLS violations, code injections, vulnerable third-party libraries, and more. Clayton works with GitHub, Bitbucket, GitLab, and Azure DevOps. Go to getclayton.com/salesforceway to get one month of secure development essentials for free. It's getclayton.com/salesforceway. You can also find the link in our show notes. Clayton build on Salesforce, stay
[22:01] secure.
[22:07] I see that is kind of like untangle this big monolithic compiler thing, right? And then you somehow let it to align with this new product or the language service, so that it's more flexible. Yeah, it also made it just easier for us to do things like change the definition of annotations. In the old compiler, they were much more hard coded. Annotations and all their parameters were something that took a lot more effort to modify. And pretty much every release since I took over as PM, we've made some change to a new annotation for flow support or. A new attribute on an existing annotation, and that used to be a fairly intensive piece of work. And now I actually have like that file in the GitHub in our Git repo bookmarked, so I can be like, oh, okay, there's the spec for it because the code that describes the annotation rules is so elegant and simple. Even though I am terrible at understanding compiler internals, so like, oh, okay, yeah, that obviously is how it works. I don't have to go bug an engineer; it just makes sense. And so, that type of quality of life and ease of maintainability was also a big factor in the new compiler. I see. How far we are from a local compiler Apex compiled. So you have a local compiler today. You just can't do anything with the output. The language server is compiling Apex. It's just not saving the bytecode anywhere. Um, but the runtime is joined at the hip with Salesforce
[23:37] today. The messaging namespace that sends email, that doesn't use SMTP. That writes to a table in the database that's then picked up by a whole separate service that runs in the Salesforce data center for sending email. Okay, and so you wouldn't be able to send email locally because you don't have a swarm of mail servers that are already preconfigured to handle picking up mail from the database and then actually sending it asynchronously. You would be missing Chatter because you don't have those Java APIs running locally. You'd be missing so the whole Connect API namespace wouldn't work. You'd be missing DML semantics because there's a layer of the platform called the Universal Data Dictionary that actually is our object relational mapping and schema broker layer, and you wouldn't have that, so you wouldn't have any knowledge of S objects. And so the idea of of trying to run the subset of Apex that remains locally is something that's so materially different than what Apex actually is in practice that I'm I don't think it actually has as much value as you would expect. Okay, there are many features we do need to talk to the Salesforce backend, right? Otherwise, okay. When you think about the structure at Salesforce, it tends to be small empowered teams. My team doesn't actually own the messaging namespace that sends email. The email infrastructure group at Salesforce does because they own the underlying mail sending logic. So if we try to reimplement their APIs just in Apex, they've already exposed the Java API internally
[25:08] before they had the Apex APIs. So it was really a request of take the existing Java APIs and write an Apex wrapper around them so people can call them. But the underlying service is still inherently part of the Salesforce core app server, which is not at all a lightweight container. Okay. Well, maybe one day because as a local compiler that has all the features that we can really use, at least the most of the features, it really it's a compelling feature that all the developers really want to have. It help us so much, if possible. Yeah, in a literal sense, it's possible. But I don't think what you get is what you're looking for. If you just want to run unit tests on arithmetic, yeah, that could probably run locally. But that's not what you're writing Apex for. You're writing it for triggers. You're writing it for invocable actions that interact with flow. You're writing Apex REST services, and without the other elements of the platform that empower those. They're not really that useful. I get the point. Yeah, the biggest hope in that area is probably Evergreen Functions Apex support, because for that we will have to have a limited subset of the Apex standard library supported, because it's not the traditional Salesforce execution environment. You don't have a synchronous database transaction; things will be written back through APIs. So it's a fairly material difference from how Apex traditionally runs, but we still have a lot of the services available. So. A lot of the Apex standard library will be available there, but not all of it. And so that's
[26:38] the the first time that the execution environment of Apex is radically changing, and that is a potential. Step in the direction that you're talking. Could you first of all to brief us what is this evergreen? I know it it was coming, but a lot of people don't know what it really is. Sure. So evergreen is. Taking Heroku and Salesforce platform and uniting them, not just in terms of theoretical capabilities to interact, but as a first-class citizen, as a true metadata type. So one of the goals of Evergreen Functions is that they'll be able to be packageable. So you could write an Evergreen Function in Java, JavaScript, Apex, and package it in a managed package. And that would be available to the package consumers, and so it's it's really taking the taking the managed aspect of Heroku, and. Making it so that it's managed. That there's a new variant of it that's managed by Salesforce. Obviously, classic Heroku is never going to go away. It's a wonderful tool, but if you want to bridge Salesforce and Heroku today, you can do that definitely. And a lot of times, it's not that bad. In fact, a lot of times, it's great. But there's also scenarios where you want. Special permissions. So you may want a service that's running on Heroku to always run with the user permissions of this specification, no matter who's invoking it. And if you passed a session ID from from Apex in Salesforce over
[28:08] to Heroku, it would have the user's permission and not the permissions of the service that you would like it to run on behalf of. And so, making it so that there's the notion of service level permissioning is something that's done to. Kind of interact and improve the integration story between Salesforce and Heroku, so that it's if you already have a big investment in Salesforce and Apex and Visual Force and Lightning. And you would like to add Heroku to augment that without fundamentally changing your architecture, and you'd like to minimize the number of hurdles because you already like your architecture. Evergreen functions are going to be wonderful for that because they solve a lot of these problems for you without any custom work, and will manage the Heroku infrastructure as well, so that. If you want a lambda processing language to be integrated with Apex as a first-class citizen, that's what's going to be really interesting. But I naively understand it as a hybrid solution. Yes, because at the moment, it's an Apex is the only native language on the platform, the Lightning platform, right? So in the future, we could have Java, we could have Ruby, JavaScript, all running together in a hybrid mode. Yeah, they'll they'll be running on Heroku infrastructure, so running inside of a Heroku Dino. Apex will actually be in in the context of Evergreen Functions. Apex will be supported. So Apex will be running on a Heroku dyno, if you want. Yes, so you can use Apex, but it's going to be a little bit different than traditional Apex because it's not.
[29:39] Tied to the database transaction in the same way, so there is still some details being worked out, but Apex will very definitely be supported in this model. It'll just be a little bit different than traditional Apex in a few ways, mostly around database interaction. Okay, so the current Apex running on the platforms still remains, but if you want, no changes there. Apex on, okay. Yeah, that's interesting. In fact, I'm excited. So one of the problems I have is that a lot of large customers keep asking, "How do I buy more batch Apex capacity?" And there is a finite pool of asynchronous capacity. And sometimes there's a little bit of leeway. Sometimes there's a little bit of extra that we can turn up limits temporarily or even permanently if they're modest on number of asynchronous executions or occasionally number of concurrent batch jobs. But there really is a hard limit just based off the capacity model of the core platform. Where if you wanted to do another billion async transactions a day, that isn't something that the elastic scaling is there for very effectively right now. And a lot of that is tied to how it's synchronously part of a database transaction. Adding another billion long-lived database transactions is not a trivial operation. And so that's one of the areas I'm really excited about Evergreen on is if you want to scale up beyond what Batch Apex can offer, and but still have it integrated with Salesforce as a first-class citizen. They're going to be really promising for that. I'm really excited about that.
[31:10] Another one is Apex is not designed for processing binary files, and the people I've seen who've tried to do things like process zip files in Apex, the like the zip file library that the community has written for Apex that does string manipulation and then base sixty four is it as a way of manipulating binary files, not efficient, not not at all, and so there there are. Workarounds for doing binary file processing in Apex, but it's not what we're designed for. It's not what we're good at. It's not what we're optimizing for. So if you want to process a gigabyte CSV file, You want to do that on Heroku, and then take the processed results and write them into Salesforce. And so that's the type of things that I'm seeing immediate adoption on Evergreen Functions once it's out. For is the places where Apex has been shoehorned in, even though it was the wrong choice, because it was the only thing that was native to the platform. And now there is a better tool for those jobs that's also effectively equally native to the platform. So, Apex is is running one hundred and five billion transactions a month at this point, just from paying orgs, not including others. Our growth rate on transactions is fifty three percent year over year growth right now. So. The volume of Apex growth is massive, and at some level, it's almost concerning. This just huge number of transactions, this huge volume of growth. On one hand, it's very encouraging, and it means I'm working on a product that's impactful and empowering.
[32:40] On another. I worry about Apex being used in ways that it's not effective at at scale, and the problems that that can cause. And so, in a sense, I'm actually really excited for Evergreen Functions because if I can slow the growth of Apex adoption slightly by offloading the things it's bad at, that's actually really good for the health of Apex. That's really good for the health of the platform, and it opens a lot of doors to new innovation that are really exciting for me. And I've looked at Flow in a similar way, actually. So I did a presentation at Dreamforce of Apex and Flow showdown, but then the whole presentation was about how you can integrate Apex and Flow very effectively and have better results on each one individually. And in the same way, I'm kind of looking at flow and the improved work around invocable actions that they've been doing, supporting generic S objects, supporting concrete Apex complex Apex types. There's a pilot program for LWC-based invocable action configurations in the flow designer. So they've been investing heavily with some help from Apex in making it so that Apex actions are first-class citizens in flow that are as powerful as anything we could build ourselves in Java.
[33:49] Because there's a lot of Apex that is really copy and pasted code that takes a SOQL query and bridges the results to a Lightning component, a Visualforce component, etc. Where there's an argument that that isn't the right place for a code solution. A low-code tool that has a little bit of code augmenting it for the particularly innovative or interesting or challenging or for surgical security escalation, what have you, is a better model, and it's something that's easier for admins to maintain. And so, I am actually kind of excited in the same way to offload some of the places where Apex has been used because it was the only tool historically to flow, where it's easier to configure and easier for admins to manage. Instead of an admin writing a spec that looks like a flow and handing it to a developer, they can build a flow and have the one black box of an Apex action that does the heavy lifting in terms of system mode or in terms of security sensitive or performance sensitive operations. And so, I am trying to look at the platform holistically because. I'm not at all worried about my adoption being too low. I'm worried about my adoption being too high for the wrong reasons. Okay, I get it. This is a really good, you know, conversation with you because before this, I had no idea. I thought you were worried that because Apex was the only native one, and now it's like taking the weight out. I thought you had some concern, but it's more positive in in a way here. It'll make my job easier because I will deal with less escalations. Where, hey, we want to process fifty megabyte files and doesn't
[35:19] work right. Yeah, sorry, that's that's the way the limits work. Because it seems to me that for the Salesforce developers now we have more people from the other technical stack joining us, like Java, Ruby, you know those JavaScript. So they are joining the force. And for the architect' point of view, it's more like microservice now that you need to build on top, you know, to form a good architect. So that's not an easy task. It also, I mean, I personally look at it as more of a spectrum of. There is a level of comfort with customization and technical complexity that is a wide spectrum. You know, you could try and define like three or four personas along it, but at the end of the day, there's somebody at basically every point of the spectrum. We have enough customers that that that's just true at this point. Where at one end you have. Pure declarative environments. The only interaction they might have with a developer is occasional contract engagements, and even those might be hard for them to get. And that's definitely something that is a very real thing in the small, medium business, even small, medium enterprise. Salesforce developers are hard to justify having a full time engineer with a very specialized skill set, unless you really are at the scale where you have a full time person's worth of work that you can justify. And so, in that type of context, I mean, that's why workflow was so popular. That's why Salesforce took off as a platform. Is
[36:49] it was really easy to customize and do some basic enhancements to, without needing a developer, and so that that aspect is still alive and well. That's a core part of what we think about. And that means you have Process Builder, you have Flow, you have Workflow, you have custom objects, and you're not going to touch anything programmatic. But that's a non-trivial part of our customer base, and what Apex there is needs to be something that is long-lived without a ton of maintenance work. And so that's where I think about invocable actions and Flow being really useful. Is you can make a well-specified, well-defined, highly configurable Apex action that's integrated into a Flow app, Flow invocable. And that can have a really long shelf life without any ongoing developer maintenance, but it can be reused by admins and flow contexts. And so, when you do have a developer engagement, you're multiplying the amount of of return you get from that if you do it right in that type of low code environment. And then you start to scale up, and you get Apex-centric orgs where they probably won't use Flow or Process Builder because they like to have Apex be the center of transaction control and save order. But they might use Flow from Apex. I've seen a lot of customers where they have a lot of Apex already; they have a lot of investment Apex triggers. They want to add Flow, so they add. Calling the flow interview class in Apex to their existing triggers for fine-grained control over where it is in the save order, and so there's this type of enhancement on top of a programmatic base with configurable by admins
[38:19] flexibility, and then you get to the. Really high scale, just really tightly governed environments, which is actually how I would describe the AppExchange org. It was entirely programmatically driven because we had millions of users and a huge volume of requests, and it's a public-facing website, so we've really had to have a good CI model where everything was source control is the source of truth. Indeed, and when you get to that end of the spectrum. Apex is the tool for working within the transaction. It's the tool for writing a custom controller for LWC where you have trusted business processes. It's the tool for writing triggers.
[39:00] So Apex will pretty much always be the king of doing logic in the transaction, if you're at that end of the spectrum. But what we've learned is, holding open a giant database transaction is really a model that has a limited scalability point, and at a certain point starts to be counterproductive. When you realize that Apex is a ten second synchronous CPU limit, you don't want to wait ten seconds after you click a button for something to happen. So to make things scale beyond what we have today, where it's in the transaction, we need things that are event driven, that are asynchronous. And that run in a different model. So Apex is going to stay king of owning the transaction, transactional processing inside the Salesforce platform. But that's not always the tool you want to use. There's a lot of things that you should and could defer, and that's where platform events are really popular. You can still use Apex to do asynchronous events that way at at a fairly large scale, and I see Evergreen Functions kind of fitting into a different. Part of that same model of get non critical path work out of the transaction for the sake of performance and scalability, and run it in whatever the right tool is. And that could still be Apex running on functions. It could be Java if that's the developers you have in house. If you don't have a dedicated Apex dev staff, it's hard to justify doing that at certain points on the spectrum. And so, I'm not worried at all because this spectrum is massive and has.
[40:31] A spot for Apex to have a glorious future at every point in it. That's good to know. When we look at it holistically, it's a healthier position for Apex too, because then I don't need to introduce new limits because you are not being incentivized to jam too much stuff into the transaction. So we can make it more developer friendly. We can make it more end user friendly by being performant. And we can set the right incentives so that we aren't having to fight with limits all the time. So it's it's a better experience across the board to have these new tools that are better fit for purpose in some of these use cases. Great! Thanks for sharing this. I'm more happy than when I heard this evergreen platform and the way that Apex developers are. Hi, this conversation continues on the next episode. See you next week.
