Today, Nate Totten, Product Manager for Developer Tooling at Salesforce, is on the show to share his insight and wisdom on some of the various tools now available to developers. We discuss a few changes that have come to tooling, especially VS Code and the Salesforce CLI, and what we can expect to see on the developer roadmap in the months ahead. We also have a conversation about the developer release cycle, how it works, and how it helps to keep Nate and his team on track, week after week.
Show Highlights:
- How a weekly release works when it comes to communications and new features
- Updates for VS Code, including new autocomplete
- Convenience features recently added including improved support for ApexDocs
- Updates to the tools that help managing your local code with orgs
- Release of local development as a beta: how it works and how developers can take part
- The desire to bring more development of the Apex platform locally
Resources:
Episode Transcript
00:07
Nate: Working closely with engineering, working with customers, you know, looking through GitHub issues, we just sort of, you know, try to find the things that are going to be the most impactful.
Josh: That’s Nate Totten, Product Manager for Salesforce Developer Tooling. I’m Josh Birke, a developer evangelist at Salesforce. And here on the Salesforce Developer Podcast, you will hear stories and insights from developers, for developers. Today, we sit down and talk with Nate about a lot of the recent changes that have come to tooling, and also things that are on the roadmap, And to kick things off how their release cycle works…
Nate: We release typically every Thursday. So yeah, we have a weekly release cadence. We do time some things based on the three releases the day that I don’t actually know what it’s called publicly, we call it internally but whatever the essentially the day that all the orgs are upgraded to the new version. We do typically do a release because sometimes we have some stuff that’s happening.
01:00
Do a new API version or something. But yeah, we release every week, which I think, you know, it’s nice because it allows us to, you know, to release less complete features and get feedback on them. So, you know, I guess you could take that in a good way or a bad way. But I think of it as a positive, you know, where we can kind of do experimentation, we can involve the customer in the process, I mean, all of the stuff we build, or almost all the stuff we build is open source. And we really like to involve, you know, our developer community sort of as early in the process as possible, which, and one of the ways we do that is, you know, rather than spending three months building a feature, spend a couple of weeks building it, get it out there, get the feedbacks, you know, put telemetry in it, see the response, and then iterate on it. And I think that helps us build a better developer product.
Josh: That sounds like a really tight, you know, communication feedback loop. You’re putting things out there, you’re getting communication back, what does the loop actually look like? What are you using to communicate something like that on such a rapid cycle?
02:00
Nate: I mean, it’s it’s a lot of channels. You know, if from, you know, people messaged me on twitter direct messaged me a lot. Sometimes they email me, I mean, we use GitHub really heavily, which I quite liked, because, you know, it gives us more of a direct sort of channel to sort of communicate on specific issues with some of the customers, you know, it’s sometimes not perfect, you know, it’s hard to like, have an SLA on GitHub issues and stuff like that. But, you know, it’s a nice place to, to really work and get feedback with the community. But it’s a lot of places you know, it’s it’s all the forums, the trailhead, Trailblazer trailhead, forums, and Twitter and anything else in between. So, yeah, you know, it’s really more of a constant process, like because our releases are so frequent, you know, there’s not a lot of like, oh, okay, we’re gonna plan to get this thing in on this exact Thursday. It’s really just we release stuff when it’s ready. You know, if it’s checked into the main branch and GitHub, it gets released. And then, you know, we’re just constantly gathering feedback and constantly iterating on features.
Josh: So let’s talk about some of the big changes that we’ve seen recently.
03:00
For one thing, there was several updates to how autocomplete works and a couple places. Can you describe those updates?
Nate: Yeah, I mean, this is really an area that we’re always working on. We’ve recently been spending a lot of time on Apex, in particular, for autocomplete. You know, this is a big area, it’s not perfect, but you know, we’ve just been doing, we’ve been fixing lots of bugs, we’ve been working a lot on performance. One of the things we’ve been trying to focus on is making sure things run smoothly in larger code bases. So you know, folks that have thousands or whatever of Apex classes or files, you know, with lots of lines of code, etc. Sometimes there can be some perf issues, right? Yeah, we spent a lot of times on those. And there’s a lot of there’s also some of the like, nice, just kind of convenience features like recently we added support for like Apex Doc, well, he improved as support for Apex docs. So like when you do you get a code completion, you sort of see a little bit nicer, inline documentation for say, a method or class or something to add to it.
04:00
Josh: I mean, autocomplete is kind of one of those things. So it’s like when you see it in VS code, it just kind of feels so there’s, it’s like somewhere between simple and magical. Like, it just sort of pops in there. But I mean, I would assume it’s a pretty huge technical challenge to really get that thing to pop up like that.
Nate: Yeah, it is, particularly with Apex. So you know, one of the advantages of like, LWC, for example, is that we really are, you know, being that it’s, it’s really, fairly standards based. It’s, you know, it’s HTML and JavaScript, like we’re actually building on top of, I mean, there’s a lot of custom stuff there. But a lot of what we get in terms of autocomplete and things like that we almost get for free or partially for free from, you know, what VS code provides out of the box for JavaScript or HTML. With Apex though it’s, you know, it’s entirely custom. We have to write the whole thing and yeah, you know, it does get pretty complicated. I will admit that sometimes as a, you know, as a product manager always like you always want more and, you know, I will admit, sometimes I’m like, why can’t we just get
05:00
You know, it’s so simple, like, it’s a list of suggestions. Right. But, you know, it turns out that it’s a it’s a pretty complicated problem. You know, one of the really interesting things actually, from way back when we first started this is the thing that provides autocomplete is called the language server. So the Apex language server. So one of the interesting problems there is a language server actually is it’s similar to the compiler in the sense that it’s like parsing code, you know, creating this tree, and then you know, so that you can sort of look up, you know, state or whatever, in a certain place in that tree and provide relevant then suggestions. But it normally in a compiler effectively, like it really only cares if the code works if the code doesn’t work. If it’s invalid, you know, it just explodes basically, right, like anything and you know, you think about that, like deploying Apex code to an org. If it doesn’t compile, it just doesn’t work. And then we don’t need to go any further and we don’t need to worry about it. Right, because right, there’s no reason for it to be there and nothing needs to happen but with the language
06:00
server that’s not the case, like your code is almost always not in a working state. So then a lot of the work we had to do was was go into the compiler, and you know, make it handle like partial invalid conditions, you know, so that we could provide, you know, completion so that you could get your code into a valid state.
Josh: It looks like we have some updates to the project template to make it easier to run Apex and also to run SOQL.
Nate: So yeah, those were always there. That this is actually one of the rare cases where I write code, I actually created that pull request, every now and then they let me do that.
06:36
It’s one of the our engineer leads, Luis, he sort of always hassles me because, and rightfully so, because I do send pull requests for features, but I will admit, I almost never include tests on them. So
06:51
except that, you know, he gets the pull request and I’m like, Hey, this is can we get this in? And then he’s like, yeah, you know, and then oh, and then he hopefully Spend some time and fix it and add tests. Yeah.
07:04
Excuse me, just one second.
07:07
Crying the baby woke up for the nap. I’ll just hold him while I’m talking and should be fine. Good times.
07:15
Josh: I have two cats. I mean, honestly, like, it’s so weird actually. Because like my personal life in a lot of ways is simply not disrupted at all. I already work from home, but been doing it for years. You know, my wife, she’s been working at a flower shop, but it’s really kind of more like a hobby job for her kind of thing. So the fact that she’s home, it’s actually not weird for us at all. Yeah. And you know, you don’t homeschool cats. Right? So it’s like,
07:42
it’s not a big deal. So, but at the same time, I was on the, on the line with somebody else who’s kind of in a similar situation earlier. And I’m like, but it’s still weird, right? Like the world is so disrupted right now. Like it’s impossible not to be disrupted, basically.
Nate: Yeah, for sure. Yeah. I mean, we have a three year old and a three month old and it’s a battle. It’s chaos right now, basically. So yeah, my wife and I both work from home, as well. So you know, the differences just now he has kids around all day, daycare, so and schools are closed. So yeah, so we can champion on and we’ll take what we can get.
Josh: And I think if there’s ever a time that I can put an asterick on an episode and be like, special guest is on this episode. It’s Nate’s kid. I think people will understand.
08:31
Nate: so yeah, he’s supposed to nap. But as tends to happen, he woke up early, has an agenda of his own. Yeah, actually, sorry. Let me just see if my words hold hold them.
Josh: I did actually was the episode I did with Chris with Chris Peterson. So I’ve got two cats. One of them is a very rambunctious two year old and she was sleeping in the study when I started the interview, and I usually kick her out but she was fast asleep, so I’m like, just gonna be fine. It won’t be a problem. And then like the moment Chris and I actually start recording, she’s on my desk, and five seconds later, she’s asleep on the laptop.
09:12
And then five seconds after we’re done with the interview, she was back in the study, like, it’s just also sitting around the laptop while we’re doing the interview. And as soon as we were done, she’s like, it’s boring now.
09:24
Nate: Nice. Okay, cool. My wife actually was able to take him she’s just sitting at her desk doing some work, so, yes. All right, cool. You’ve got like a blooper reel here where he can be crying baby.
09:38
Cool. All right now I’m good again. Okay, so another thing that’s always been difficult within or not maybe difficult, but a little bit of a challenge, at least with VS code has been managing orgs themselves. What kind of hands and enhancements are we seeing there? Yeah, so we’ve gone through an evolution of this and this is this is actually one of the areas that, you know, kind of demonstrates the philosophy of like little releases.
10:00
Get the feedback, etc. So, you know, we started in the very, very beginning, there was a little button down at the bottom, you know, in the in the status bar where you could click and open the arc. And then, you know, people are saying, you know, be really nice if I could, you know, see the list of orgs. And so, you know, so we added like an org picker, so that now there’s a button where you can see the org that’s currently authorized. And you there’s a little button that you can still open the art, but then if you click that authorize button, it shows you like a list of all the other orgs. And we kind of did a couple iterations on that I can’t remember exactly the, you know, the flow, but it kind of went from, I think you could see the list, you could pick it, and then we made it so like, you could create a scratch or, or, you know, we added some other functionality, like authorize a dev hub, etc. So yeah, we’ve expanded on that, you know, just to make it kind of a little easier to switch through, you know, things you could do in the COI, but now things you can do through the UI. And then you can also see in the org browser, if you’re connected to a sandbox, you know, you can see the org that you’re connected to, and, you know, see all the metadata in there. And that’s something that I think
11:00
Continue to iterate on, like, we may eventually make it. So, you know, you can maybe see multiple orgs in there, if you’re working with, you know, multiple sandboxes or something like that, you know, maybe where you can see a list of your different scratch orgs. And you can, like, delete them or something. So, but you know, it’s just one of those things, like, we get the feedback, we prioritize based on the feedback, and we go from there.
Josh: Nice. And it also looks like it’s easier than ever to track changes between your org and what you’re doing locally.
Nate: Yeah, we’re continuing to improve on that. I mean, we started, you know, again, very iterative approach, like, started with that org browser where you could you know, you could pull changes from your origin but there was no you know, that was it like you could pull it and if you’re using get it worked pretty well because, you know, you could pull a change, see then the diff and get and you know, and see what, you know, the difference between you or whatever, but obviously, not everyone’s using source control. So that enabled it so you could diff between, you know, your local stuff and what’s in your org and then we’re, you know, we’re expanding on that to do even more work.
12:00
We’re like, you know, where we detect conflicts when you try to do a retrieve or a deploy, and I warn you about it, you know, initially, it’s just gonna be a warning. Eventually, the goal is to like, give you some UI to resolve the conflicts. So just, you know, just continuing to make that better and better over time. And focusing to the local development angle, though.
Josh: So we’ve got local development out as a beta, I believe, how does the beta work? How can people get into that?
Nate: Yeah, so right now it’s local development for Lw c. So, you know, we’ve effectively taken me LWC being written in JavaScript, it can run on a node server. And you know, I mean, the compilers in node and it runs client side. So we, we were able to do something that was, you know, up to this point, unique to the Salesforce platform where, you know, we could actually take a piece of the platform out and build a local experience for most of the platform is, you know, it’s harder with something like Apex or in the past with or because it’s like, super tangled into this giant monolith of you know what an org is. So it’s one bit out of it and and run it locally. But with the way LWC was written, we were actually able to do that. So we built a with a team built, you know, and also working with the other teams, of course, built a local server that, you know, compiles your lightning web components and then runs the server locally, and then allows you to, you know, to preview those. Yeah, as you mentioned, right now, it’s in beta, we’re working to continue to improve on that, you know, and then eventually ship kind of v1, hopefully fairly soon.
Josh: If I recall from Greg talked about this briefly, all you have to do to get into the beta switch is basically add the plugin to the CLI. Is that correct?
Nate: That’s right. Yeah, we have different you know, sometimes beta or preview or whatever, you know, a lot of people think of, there’s sort of different definitions for what what we do with tooling versus what’s in like an org. Yeah, our beta is literally just install a plugin. Everyone can get it. It’s totally free. available.
14:00
But you don’t need to sign up for anything. So yeah, you just install a plugin. And it works. Once we have the V one release, it will be included with the Salesforce CLI out of the box. So there won’t be any additional installs.
Josh: It’ll just be SFDX update.
Nate: Yeah, exactly. Exactly.
Josh: Nice. And to kind of pull that into a full loop. We can also now run just tests in VS code.
Nate: So there’s a lot of things we can do with JavaScript without having to come back to the platform. Yes, yeah, exactly. I mean, you can run just tests locally, and you can see that run them and see them visualized inside of inside of VS code, for sure. Yeah. And, you know, that’s something that we want to keep doing more of, you know, it’s, it’s not that we’re probably ever going to bring, you know, Apex locally, but we want to start as much as possible, start bringing more bits of the platform to run locally. So one example is lightning layout pages are as you know, most as developers know them as like, the Flexi pages, right? You know, it’s a metadata file, an XML document that describes the layout of
15:00
You know, have a particular page and, you know, we can take the logic, we, you know, we’ll probably reimplemented node whereas it’s, it’s written in Java in the in the actual org, but you know, we can take the logic out and build it the same way so that we could actually run a local have a local experience for that Flexi page, just as it would be, you know, in the Oregon, so we’re going to try to keep doing more stuff like that to to bring, you know, more and more of the org locally and then for the things that we can’t do locally, we’ll, you know, we’ll we’ll try to enable, like, the seamless, you know, proxy or integration experience. So for example, with LWC local development today, like you can do data operations, you know, pull a pick list or, you know, do crud on an object or whatever, and that that doesn’t run locally, you know, because it needs an org, but we proxy those requests to the org. So you know, it feels very seamless and very local.
Josh: Gotcha. Is there is there a feature in the CLI or in VS Code that you really want to give a shout out to that you want really want to make sure developers are utilizing
16:00
Nate: Let’s see. Well, one that comes to mind, I guess right now is our Apex replay debugger. I think that that’s something that it’s not a new thing, but I have telemetry on the usage and the usage is still lower than I think it should be. Like, I think that it’s, it’s one of the, you know, the most underutilized features for, you know, obviously, it doesn’t apply if you’re just developing LWC, or aura. But if you’re developing Apex, like, you know, that’s a really good developer debugging experience. I mean, you know, you can, you can step through your code, you can, you know, put a breakpoint, inspect variables, etc. You know, it’s not real time, but you can download log, you know, you can run a test, then download a log, and then step through it. And it’s, you know, it’s, it feels like real time, right. And so this is a podcast, so I can’t really put up a safe harbor slash forward looking statements slide where everybody can kind of take a pause and visualize that in their heads, anything on the roadmap that you both want and can give a shout out to? Yeah, so you know, there’s a
17:00
A couple things that I think we’ll you know, we’ll continue to iterate over the next year and focus on one of them is going to be local development. As we talked about earlier, you know, we have the V one coming out, you know, soonish, you ever probably saw the, the, hopefully everyone saw the announcement for evergreen at Dreamforce. We’re looking to enable, you know, a local development experience that sort of integrated with the LWC development experience with you know, with with evergreen as well because that sort of the same thing, it’s no Jess so we can extract parts of that and run it locally. You know, so we, we have some plans on some new just convenience things inside of VS code. For a long time we’ve been wanting to add more, you know, more schema based validation. So for the JSON files, like the scratch our definition, the project definition, we have a schema for that, that provides some limited validation and code completion but it’s not complete like in the scratch our definition. For example, we would like to have that file be auto generated to include like all of the scratch features. So you know, as you’re typing, it validates, like, Hey, this is, uh, you know, if you miss type the feature, whatever, because that that sort of stuff is like, you know, it causes pain, it’s maybe minor sometimes but it’s it’s just inconvenient. And then we also want to do the same thing for the XML files so that you get, you know, validation and code completion for the the metadata files. Let’s see. Oh, yeah. And actually, one other really cool thing that, you know, that we’re working on is we’ve shipped some initial improvements to SOQL, but we’re gonna, we’re continuing to kind of invest in that. So we shipped kind of a it was like a beta preview. I mean, it’s available for everyone. But it’s it’s definitely not complete, you know, full code completion for soccer, but we’re going to continue to iterate on that to make it easier to write soql queries both in, you know, a dot soccer file, but also inside of Apex. We’ve been investigating tools around performance analysis and profiling in, you know, in Apex, that’s something we’re still doing a lot of research on it.
19:00
I don’t know where we’re going to go there. But, you know, there’s kind of a, I’ll use this as an opportunity, if anyone has any, you know, wants to chat about that, you know, where they would like to see us build tooling to help, you know, make more performant Apex code that it’s something we’re looking into. I’d be happy to chat with anyone. Yeah. So, you know, there’s a lot of there’s a lot of stuff. I mean, check out the roadmap, let us know what you think. But yeah, I think we’re gonna have some pretty exciting stuff.
Josh: And that’s our show. Now, before we go, I did ask Nate about his favorite non technical hobby. It turns out it’s one that’s actually near and dear to my heart, or more specifically, my dad’s heart, woodworking.
Nate: Yeah, so I’ve built you know, I built our dining room table A while ago, which my wife is very happy about. She was wanting a you know, a proper dining room table for a long time and I kept, you know, not wanting to buy one because I wanted to build it and, and, you know, I eventually, you know, she definitely wanted to buy it a lot sooner than I built a bunch I got around to building it.
19:58
A few other things, you know, just some tables and some shelves, and things like that. So, yeah, I’d say I try to do like one or two things a year. You know, maybe when I’m older and retired, I’ll be able to do more than that. But for now, that’s about all I can manage.
Josh: Nice. Well, I gotta tell you, that’s actually a really cool hobby. And the corner bookshelf that I’m talking into right now, is something that my dad built, and I’ve had since then, yeah, it’s actually kind of a special piece of furniture for me.
Nate: Yeah, that’s that. I mean, that’s the reason I do it as well, my desk. Actually, I have my desk, my bookshelf and a little like toolbox that’s kind of drawers in in my office are actually all things my dad built. So he was working. And so I kind of as I got older, I started to get into it.
Josh: So thanks to Nate for the great conversation about Salesforce developer tooling. And my thanks to you for listening. If you’d like to learn more about this podcast, head on over to developer.salesforce.com/podcast for previous episodes, show notes and links to your favorite services. Thanks again, and I’ll talk to you next week.