Episode 65: Modern App Development with Mohith Shrivastava

Mohith Shrivastava is a Lead Developer Advocate here at Salesforce. His main role is to inspire our developers. In this episode, we talk about modern application development. We also discuss the content that Mohith has been producing himself in order to get that information out to you.

Mohith has a background in hardware engineering and consulting. Eventually, however, he learned about Salesforce and transitioned into the world of software engineering. Now he produces relevant content and answers questions for developers and gets their feedback on the technologies they use. Tune in to hear more.

Show Highlights:

How Mohith was first introduced to Salesforce.
His exposure to product development.
How he learned about and started hosting weekly Trailhead Live sessions.
The goal of the modern app development series.
How Mohith uses Heroku to scale his applications.
How using tools besides Apex help with scaling and efficiency.
How Salesforce functions simplify coding work.
How Schema Builder helps with building data models.
When to use Salesforce, Heroku, Heroku Connect, and Redis.
How the Apex piece fits into the jigsaw puzzle of modern app design.
The benefit of having unit testing in place.
What sketch tools and plugins allow you to do.

Episode Transcript

Mohith Shrivastava:
… I would say my role as a developer advocate is to inspire our developers, also listen to them on different channels, produce content that is relevant to them, answer their questions and [inaudible 00:00:26] on Stack Exchange, also produce content in form of blogs, also get their feedback around different technologies that they use and see, also collaborate internally here with product teams and R&D teams.

Josh Birk:
That is Mohith Srivastava, lead developer advocate here at Salesforce. I’m Josh Birk, your host for the Salesforce developer podcast. And here on the podcast, you’ll hear the stories and insights from developers, for developers. Today, we sit down and talk with Mo, about modern application development and the content that he has been producing in order to get that information out to you. And we start as usual, with his early years.

Mohith Shrivastava:
We also had some electronic subjects like Verilog, or MATLAB. All those had a little bit of programming with respect to hardware. And also I did code 8086. So, one of my subjects was at 8086, in which we had this, you have to program registers, transistors, and things like that. So, I did those kind of instructions as well like writing a movie command to move, allocating memories, and stuff like that. So, that was also interesting to me. But later, I realized that in India, there’s not a lot of scope for hardware programming. So, software was only our choice. And then I moved to a consulting world where my first experience was working with an ESB software, like enterprise service bus. And I was tired of starting and stopping the server.

Mohith Shrivastava:
So, it did not sort of go well. Like after three months, I was not interested, my mentors were no more motivated. That’s where I heard that there was something called Salesforce actually, which was pretty exciting. And there’s not a lot of talent in that technology. This is back like 2011. So, I got a simple assignment of, “Hey, can you build these objects for us as a part of this project?” I started working on building objects, and then the requests slowly started moving to something complex, like, “Can you write a trigger for us? Can you write this Apex Service for us?” That’s how I started into Salesforce world.

Josh Birk:
Interesting. How did you find going from that kind of very distinct structure? Like you’re using something very server specific, you’re coding and see, and then, what was what was your first reaction to doing something like creating a custom object with a wizard?

Mohith Shrivastava:
You know, Josh, I was super excited. The moment I saw the Salesforce interface, and the speed with which I could click through the application and build a complete application in like two days. Josh, do you remember that in those days… And I know you were an evangelist in those days, I used to attend a lot of your sessions. So, thanks for those. But we used to have this recruiting application cookbook, where it used to take you through a journey of how to sort of build an application, how to define your data model, how to write your security for the application, right? So, I use those resources, actually. And I was surprised in within like three days of coding, I had an application pretty much working end to end.

Mohith Shrivastava:
I could really see this is really quick and everything made sense. For example, in Java, I was always like, “Why do I have to write a class? Why do I have to create an attribute?” That never was clear to me because I was never exposed to data. And I was just coding at the application layer. So, I was never exposed to like, “Okay, how are my end users sort of using this application?” Because I was sort of a back-end web service developer, right? So, getting that front end exposure and an end to end application exposure did play a very important role in my career, because then I was like, “Okay, no more, I want to be specific to one specific thing. I want to be a full-stack developer.”

Josh Birk:
I like that there are a lot of people who’ve come into our ecosystem because they got tired of spreadsheets. And so they found something better, but you kind of came into our ecosystem because you didn’t want to restart a server anymore. And then when did you get an opportunity to come over to the States?

Mohith Shrivastava:
Yeah, I think it was five or six… I think it was five years back. I got one of the projects that my previous firm wanted me to come onsite, because there was not lot of developer talent at that time here. And the project timelines were really very small. So, they wanted some onsite developers so that they can reduce that time of communicating back and forth. And communicating between different parties can also mean that you’re losing a lot of information all the way, right? And by being at onsite, you can really sort of ideate upon, you can bring your own ideas, you’re designing in the same room with your architects, right?

Mohith Shrivastava:
So, that provided me to an opportunity to come here and work. And I’ve worked there for some time. And then I was really interested in end-to-end product development on Salesforce. Till now, till like first five years of my career, I was just doing system integration work, meaning I was like, there is one art that the client has, and we were trying to make that work and configure all the business processes. But then, I explored this product development world, that is our ISV AppExchange applications that one can build on Salesforce. So, I explored that world and I got more interested in that, because then I was like, “Okay, I can build a solution that can be used in multiple number of arts.” And that’s where I decided that, “Okay, I need to work with a PDO, like a product development outsource, which essentially have our ISV clients as their clients.”

Mohith Shrivastava:
So, I joined the PDO, there I worked as a developer, and then as a technical architect, and we build some amazing applications. And a lot of companies are very successful on AppExchange today. Some of them have gone as public companies also. So, they’ve grown to a really good extent. So yeah, that gave me a whole new world of exposure around product development. And that, got me more excited because I wanted to always explore like, “Okay, what does it take to build an application on Salesforce? And what are the different steps that are that are necessary to build a complete product on Salesforce? And how does the deployment look like? How does the support look like, and how does… It’s being sort of used by end users? And what are some of the challenges in that process?” So, I was lucky enough to spend a lot of time there, in the product development world here.

Josh Birk:
Nice. And then, how would you describe your current role at Salesforce?

Mohith Shrivastava:
That’s an awesome question. I’m learning every day, actually. And specifically, I joined Salesforce when the pandemic sort of hit. Earlier, I had this impression of, “Okay, I’ll be going to different meetups and talking to developers.” Of course, one day we will. One day hopefully will, right? But everything got digital. So, I sort of started looking into, “Okay, how can I contribute in this times?” So, I slowly started sort of working with other developer advocates here like Kevin, and sort of seeing, “Okay, how can I best contribute?”

Mohith Shrivastava:
Then I learned about this Trailhead Live. So, we do Trailhead Live… I do Trailhead Live sessions every week, almost every week at least one session. That was really good exposure because then I can pretty much live stream. So, I was also very new to like live streaming, more of Webinar kind of person, right? But yeah, it was an interesting challenge for me to learn all these tools and technology, to go live stream something.

Josh Birk:
Got it. That’s an interesting point is that the transition that, we’ve had a lot of this year, of like Webinar to live streaming. And I think somebody listening to this might think, “Well, that sounds like kind of the same thing.” How would you describe the distinction? And the different workflow between those two?

Mohith Shrivastava:
Yeah, very good question, Josh. Actually, both of them are different. That was also my first impression, the one that you described previously, like both are same. I also thought both of them are same. So, I went through my first session, I remember I recorded that I did not go live. And while I was recording it, I sort of realized this thing that it’s not same. Whatever I’m thinking right now, when I’m recording it, or whatever the portions that I’m sort of editing it, it should not be edited. I did not feel good about it after I recorded my first session that… I really want whatever I’m thinking to convey to my audience. Like for example, let’s say I’m googling something, right? I’m googling or I’m looking at the dogs. I want the transparency with my audience. So, that’s, that’s when I realized that both of them are really different.

Mohith Shrivastava:
In one, like in pre-recorded content, it’s really good, especially like we have this quick texts, right? So, quick text, pre-recorded content is really good because you have limited time and you’re trying to convey certain thing, right? While if you want to sort of showcase how to code or use a specific language, for example, if you’re writing a JavaScript code or if you’ve written a lightning web component, or something like that, it’s always better to go live and do that because your audience is also learning along with you. And they learn a lot of things, not only by just hearing to your content and going through those presentation, but also actually seeing you, how you’re thinking and approaching that problem. That way it is very different. You are exposing yourself to showcase how you’re thinking in live coding, which to me was very new.

Mohith Shrivastava:
And once I realized the power of it, I really started to sort of go live with less preparation as possible, like for all these sessions that we do, right? There is some amount of prep that is required, but again, I do not prepare myself a lot. And there is nothing that I practice. For example, for recorded content, you typically write certain thing, write your script, think about what message that you want to deliver, right? But on live code, it’s usually like, I pick up a requirement, and then it’s like, “Okay, let’s code it.” And it’s not that you will get the output every time, it has happened to us in the live code that we struggle on a problem for some time. And that’s also part of the learning that I want to be really transparent with our developers here.

Josh Birk:
Gotcha. All right, let’s talk a little bit about that content. Tell me about the modern app development series. And what’s the goal there?

Mohith Shrivastava:
Absolutely. So, modern app development on Salesforce. Now, we came up with this idea that… I looked into what is the future of Salesforce application development? So, I spent some time with other developer advocates leadership here. I thought about this, and then I was like, “Okay, what does it mean to be a modern app developer on Salesforce?” One thing for me, it was very clear that it is no more just Apex and Visualforce. You’re no more restricted to that.

Mohith Shrivastava:
The amount of innovation that has happened in the last two years in terms of tooling, in terms of technologies, like you know, now you can write LWC for your front end application, which is essentially you’re using JavaScript there. So, it has more capabilities than Visualforce because it was… With Visualforce and Stand Up Markup, you only had certain things, right? Obviously, you could bring other frameworks, et cetera. But now that you have this LWC, you have developer tooling, for example Scratch Rx, and all the tools that we have, like Salesforce Eli Lilly.

Mohith Shrivastava:
And also… these are a couple of innovations, right? And also some of the innovations in local tools. That also got me interested, for example, Dynamic Forms, Dynamic Actions, you can do a lot more with that, flow screens, right? Flow screens is one of the other technologies that got really excited, I got really excited about flows, especially the screen flows, like how you can quickly build a multi-page application using flows. In today’s world, again, the world we are in now digital, everything is changing to digital, and customers want really best, in like when they invest in Salesforce, they want best out of Salesforce. And for our developers it’s a challenge because they have limited time. The approach to build an enterprise application, in my experience, has been combine both the low-code and pro-code. You will need both, you need low-code, you will need pro-code, both of these combinations of tools.

Mohith Shrivastava:
And also you want to scale your applications. Now, that’s the other area where we focus in this modern application development, is scaling these applications. And it could be we are not limited by the limits of Salesforce to some extent. And we use Heroku actually, to scale our application. So, we have a lot of Heroku content here. Specifically, we learn how to write Microservices using node JS because we know that once we sort of use both of these tools, like Salesforce, [Core 00:14:39], and also the Heroku platform capabilities, then, we are more powerful, essentially. So, adding more to the mix of our architecture, right? It gives us that more capability for us to go and scale our applications.

Josh Birk:
Right. Well, in using that as a segue, we should give a shout out to your core collaborator, Julian Duque. How important is that collaboration been for the series?

Mohith Shrivastava:
It’s been awesome collaborating with Julian because I am not 100%, like I’m not an expert on all the offerings of Heroku. And that’s where I collaborate with Julian because Julian brings in lot of these new excitement to the series. He knows a lot of JavaScript technologies. He knows a lot of open source libraries in Node JS. We use Node JS, right? We think that Node JS… Now the thing about node JS that’s so important to understand is it’s JavaScript. It’s JavaScript on the server. So, it’s the same language that I’m learning to write lightning web components. With some modifications and some more learnings, you can use it on server, like on Heroku writing this Node JS applications.

Mohith Shrivastava:
So, Julian knows a lot of these open source libraries, like what open source library should be used for, let’s say, a web worker, or like creating PDFs, like PDF maker and things like that. So, he has lot of those knowledge. I’ve been collaborating with him to see how we can sort of use those Node JS libraries to do some of our business arts. Like, for example, generation of PDF is a good example, right? [crosstalk 00:16:20] Or let’s say we want to do a bulk operation or invoke bulk API in Salesforce, right? Salesforce provides the API for us. Now, especially for me, I don’t have a lot of experience, like with Python, or let’s say Ruby, or something like that. Those are like new languages to me. So, I still have a lot of learnings there. But one thing I’m so comfortable with is node because I know JavaScript.

Mohith Shrivastava:
So, I’m assuming it’s same for all the Salesforce developers, they are pretty much familiar with JavaScript at this time, or the learning curve is little easier compared to other languages here. So, that’s where we figure it out, “Okay, how can we use these API’s that Salesforce provides with node JS?” And we use a lot of open source libraries like JS Forge, or sometimes we build our own libraries. Tat has been exciting to learn because… And once we have learned that art of writing those node JS, NPM modules, you won’t believe Josh, like I’m now regretting that day, why did I write so many batch epics in my previous times art. That’s I have used so much of resources that have been used for some other important business process.

Mohith Shrivastava:
So, anything asynchronous right, can really go as a microservices. And also, microservices are easier to maintain because it’s its own layer. It’s no more a monolith or a monolith application here, everything can be divided into modules. And it’s so easier to maintain that way. So, the more and more I’m learning writing node JS and sort of exposing that as microservice, more and more use cases I’m finding that I’m like, “Okay, this should probably not be an Apex batch, Apex, or COBOL interface, I would probably prefer a Node JS service because it’s more powerful.”

Josh Birk:
Yeah. Well, that’s interesting, you’ve seen a long history of JavaScript. And I can only imagine that you and Julian are spending a lot of time geeking out on JavaScript, but you’re kind of your journey to learning the tricks on the server side, which seems like that’s a lot of value paid off, like you can build off of your previous experience with JavaScript. But you’re finding all of these new frontiers of things that now you don’t even need Apex for.

Mohith Shrivastava:
Yes, exactly. And Apex is awesome. Again, I love apex, for sure. Apex is awesome but you have to, again, you have to use the right tool for the right job, right? So, it’s not like I can use Apex… Let’s say, I have millions of records, and I need to process them in batch Apex. Apex is not probably the right tool there. Because you’re consuming lot of resources, right? But if you do it in node, you will see that you can really write these applications quicker. And not only that, you can scale. You can add horizontal scaling and vertical scaling in Heroku, which is something that I learned new. In vertical scaling, let’s say my process takes lot more… it requires a lot more CPU, right? I can do a vertical scale of that. And let’s say I have more concurrent requests coming into that specific process, then I can horizontally scale.

Mohith Shrivastava:
So, that has been interesting, because as an apex developer to me, there’s nothing called scaling there. You know, it’s like you have this specific time and you have to make sure that you write your best code, so that all of the processes get executed within that CPU limit. But with Heroku, I am no more bound with that limitations. I can scale, I can horizontally scale, vertically scale. So, I have that scalable options there.

Josh Birk:
Well, I kind of feel like… I kind of feel like maybe you just answered this question but… And also feels like with all the talk we’re talking about with node in microservices and stuff like that, we should give a shout out to Salesforce functions, with the warning that I can and probably will have to do an entire episode on Salesforce functions. But can you give me the elevator pitch for Salesforce functions?

Mohith Shrivastava:
Yeah, sure. So, the elevator pitch for Salesforce functions, right? On Heroku… We are doing all of these on Heroku, right? But you will still see that there is lot more things that are required, for example, to establish integration between Salesforce and Heroku, you need a connected app in place, you need to still create your node script to run that server. And so you need like an express or we are using fast Wi-Fi for our eCash application that we showcase or we use in our sessions. So, there are still a lot of work that’s… Again, you’ll have to do the same work again and again if you’re creating more services. And with Salesforce functions the way I have learned about it, and again, I’m still learning, I’m a learner here on Salesforce functions. But what I have learned in Salesforce functions is, to create a function and actually host it, it’s pretty simple. You don’t have to do a lot of those work that I was doing, like creating connected apps, creating or managing those Express server, et cetera.

Mohith Shrivastava:
So there’s a lot of same job that you have to do again and again. And that is where function simplifies it. Also, another thing is in terms of technology, right? Like the way the Heroku works, it uses dynos and you have to yourself like sort of scale, or set the scale meter yourself, right? And that’s where I think the Salesforce functions uses all the latest technologies of container, building applications using containers. So, they use Kubernetes, and Docker. And I’m hoping again… I don’t know, I’m not an expert here. But I’m hoping they’re using Docker because I see that one of the requirements is to you have a Docker Desktop to test the Salesforce locally, right? So they’re all using the latest and greatest, that means it has a lot more innovations, the backend of it is more stronger, right? So, any day when Salesforce functions goes GA, it’d be an interesting idea to take all the work that we are doing, and use Salesforce functions for that, and [inaudible 00:22:20] the higher workflow.

Josh Birk:
I think you’re safe from pm jail, I think you got all the good nouns there. And if anybody’s listening is curious about some of the technology behind that. You can go back to the November episode with Joe Kutner, where we broke down Cloud Native Buildpacks, which one of the key ingredients, and also talked an awful lot about like the history of Heroku, and microservices and stuff like that. Okay, cool. So, moving on to a different layer of modern app design, talking about the data layer. In one episode, I have to point out, you’re using actually a favorite tool of mine that I think is underscored in our community, you were showing Julian around Schema Builder. Are there some specific things you like about Schema Builder?

Mohith Shrivastava:
Yes, definitely. So data model design, right? We spoke about it upfront because you know that Josh, if you do not do your data model. It’s like laying your foundation, right. If you do not lay that properly irrespective of your producer of Elegant UI, it’s not gonna scale. So, we wanted to take this topic. One of the topics we discussed were developer tools and then we straight away jumped on to data, like how to create efficient data model. So, we have our episodes, actually, you can go and watch, where we use schema builder and we compare and contrast actually like, “Okay, if I have to create a database, like for example Postgres on Heroku, let’s see, what are the design techniques and how long it takes to create? And let’s do that in Salesforce.” And obviously, in Salesforce, the speed with which you can build data models is really I mean, it’s really good.

Mohith Shrivastava:
So, you can build all these data models. And it’s not just the data model that Salesforce provides, like once you build data model, there’s a lot of things that’s going to come out of box, like for example, security, because you have fields, you have profiles, you have the UI layer as well, like you get page layouts out of the box, you get lightning pages out of the box, right? So you get a lot more things out of the box in an opinionated way, which is really good. So yeah, we looked into the data model. And one thing that really struck was the schema builder, because in Schema Builder, you can really create these fields and objects pretty quick.

Mohith Shrivastava:
But again our message to our developers here was, see you can build these very quickly but that doesn’t mean that you should rush into your designs. And that has been one of our key message in this modern app development. We want developers to also think through the design and not rush into things that will take time. For example, we know that data… you need to have a review process around your data model. Because let’s consider an enterprise scenario, where there are multiple teams, which are building applications and multiple applications. Now, if you do not collaborate, or if you do not have a proper process in place, what will happen is, you will end up creating duplicate data models, and you have duplicate siloed data again. So, it’s not that you’re solving any of the challenges. If you do that, you’re not gonna scale, definitely, you’re not going to scale if you produce inefficient data model.

Mohith Shrivastava:
So, that’s why we want developers to think through the process, think through their design, and then when it comes to building these, we show them how easy it is to sort of build all of them. So yeah, you know, data model has been really an interesting topic that we did. We did a couple of sessions on that one using Salesforce, and the other one was using Heroku Postgres and where Julian sort of showed how to create them, how to use them on Heroku applications.

Josh Birk:
Gotcha. And I’m curious, when you know from like the Greenfield state, and you’re starting to work through the app design of the data design, and you know you’re probably gonna go with something that’s a hybrid between Salesforce and Heroku. Are there specific considerations on the data design that you feel people should know about?

Mohith Shrivastava:
Yes, definitely. So definitely, we want developers to use Salesforce as sort of a master for a lot of the data because you can do more with Salesforce pretty quickly, for example, automation, right? They have… You can write flows, you can write Apex triggers, and you can write process builders, et cetera, although we recommend flows. So, you can do automation pretty quickly because of different tools. And also we have services on top of those data, like exposing them or locking them down based on the security and profiles. All those sort of requirements can be taken pretty quickly on Salesforce. That’s why we recommend that make Salesforce as your central data for all your B2B use cases, use Salesforce, build your data model on Salesforce right?

Mohith Shrivastava:
Now, when it comes to consumer-facing application, that’s where you need that data to show or you need to interact with that data. There you have multiple options, and the power of Heroku shines there because you can use the technology of your choice there. Like you’re not limited by saying, “Okay, you need to use lightning web components, et cetera. Although I recommend lightning web components now that as a Salesforce developer, you learn them pretty quickly. You can reuse them on Heroku as well, using node you can… Now we have also published an NPM module with all the lightning based components. So you can use it outside Salesforce.

Mohith Shrivastava:
Yeah, you can use it outside Salesforce. But yeah, the real benefit is let’s say somebody wants to build a progressive web app. Let’s say there are 100 million of users, who are consumer users like B2C users, right? So, all the front end that you need for the application, maybe you need them in your technology of your choice, like React right? Maybe you are building a native mobile application using React Native, things like that. So, Heroku really makes it so easier to build those kind of web application and host it on Heroku. With the technology choice that… With the developer skill set that you have. So, Hiroko makes a real use case. But all the data, we finally want it inside Salesforce, because then we can run all automation, we can lock down the data, we can take care of the security, and all of the goodness.

Josh Birk:
Right, and you have a demo in one of the episodes that we have the wonderful tool Heroku Connect, if there’s some kind of Venn diagram of stuff you want in both Salesforce and Heroku, or the like. Now, Heroku has access to NoSQL databases, something Salesforce doesn’t… Kind of has some comparisons to. Are there some really good specific use cases for leveraging something like Redis?

Mohith Shrivastava:
Yes, there are in all use cases. In fact, we talk about both Redis and Kafka. We also talk about Heroku Connect, like let’s say you want… Heroku Connect especially if you want to sync all the data that’s there in the Salesforce to your Heroku database, like Postgres. That makes really good use case of Heroku Connect product. You don’t have to build your connections, there’s already a product that that makes it so easy to sync that data in almost real time. No, I must say that it’s not real time, but it’s almost real time. So, Heroku Connect is for that.

Mohith Shrivastava:
Now you have Postgres, that’s your default database, and then you have Redis. So, Redis is like a caching layer, right? Let’s say you want to improve the application speed and you don’t want to go to the database again and again. That’s where you can go and create a cache layer using Redis. Think of it as Platform Cache on Salesforce platform, right. A lot of developers who are not familiar with Platform Cache, they should go check out Platform Cache. And we also did a session on Trailhead Live, as well, for Platform Cache, and I can share the links for that. So, with the Platform cCche, what you can do in Apex is, you can really improve the performance. Let’s say you’re querying the same data again and again. Instead of going back to the database and writing your SOQL again and again, you can just create a cache, like a platform cache, like a session or all cache. So, you create the cache and then you just access it from the cache. It’s like in memory store. So, it’s faster, right?

Mohith Shrivastava:
So, Redis is also same. It’s meant to improve your application performance. And then we have Kafka. And, in fact, we have an episode on Kafka as well. So, in Kafka, what we do is it’s for real time, data intake. So, let’s say you have lot of processes emitting data, like let’s say, an IoT device, for example cars. For E-cars we use IoT device. So, IoT device can basically emit lots and lots of data. And let’s say you want to stream all those data into Heroku, right? And that’s why we have this Kafka connector. And then we show a lot of use cases for that, like how to stream that data back into Salesforce real time and show it just without storing the data, we also show that use case.

Mohith Shrivastava:
Also, with Heroku Connect, right? You can use the external objects of Salesforce where you can really not store the data in Salesforce, it can still sit outside Salesforce. When I say outside Salesforce, it is still Salesforce platform because it’s part of Heroku. And it has all the security features, essentially. So, it can still be on Heroku, and you can still expose it through the Salesforce Native UI through the Salesforce Connect product.

Josh Birk:
Right, gotcha. Now, moving things to one of my favorites Apex. What are some considerations that you have in the series? And I feel like there’s parallel here to what you were just saying about, like data design, when people are starting to bring Apex into the sort of the modern app design. What should they think about when they think to like, how should that piece fit into the jigsaw puzzle?

Mohith Shrivastava:
Yeah, excellent question again. So apex, one thing to know about Apex is, there’s governor limits, so you have to know that, that there is a governor limit in place for good. It’s a multi-tenant architecture. So, we showcase all the local tools, one must know all the capabilities of the local tools. But where Apex shines is all of these local tools have ability to plug into Apex. For example, let’s consider flows, right. So, a flow automation can also invoke an apex service. So, the moment things start getting into this complexity, right, let’s say you have very complex logic, let’s say you want to use… You need to use maps because you have to pull together data from multiple objects. So, for those type of use cases, then only you go for Apex.

Mohith Shrivastava:
Or also you want to control your transaction, let’s say you want the sequence of events to happen one after the other. So, that’s where you actually use Apex, because you are controlling the transaction, you have some complex logic to write, and local tools can go only to certain limit. But those tools also have interfaces where you can plug and play Apex. Similarly, Apex can also be used for lightning web components, as wire adapters. So, you have wire adapters that can code the Apex, right? And Apex also has the power to reach to external services, like a service hosted on Heroku, or somewhere on the internet. Those type of use cases, and what I recommend for all the developers listening here is, go and check out Apex recipes, actually.

Mohith Shrivastava:
Kevin has put together a lot of time building those Apex recipes, it has patterns, like when you’re writing Apex, you need to have a design pattern in place. Otherwise, you’re you’re slowly run out into a mess. You’ll slowly start running yourself into a mess, you don’t have design patterns, it becomes very difficult to debug. Kevin has put together some design patterns around, what should be the second best practices, what are some other Trigger patterns, he shows an example of a Trigger pattern, essentially, that is how you approach. And there are a lot more recipes there, just everything that you want to learn about Apex, use cases specifically, I think Kevin has it covered. And that’s what we used in the modern app development series as well, where we showcase different recipes, and we adopted one of those code that Kevin has put together and sort of modified to our use case here.

Josh Birk:
Alright. And I have to ask this question because it’s kind of inadvertently turned into a theme on the show. And I just kind of love pulling developers opinions on this, but just describe to me how important unit testing is.

Mohith Shrivastava:
It’s extremely important. As a developer, it’s very hard to actually get into this habit of doing a test-driven development. So, again, it is a habit that you want to really have or build. It takes time, actually. But, the real benefit comes when you put together a continuous integration and continuous delivery system in place. So, with that what happens, Josh, is you will see that your regression bugs are caught pretty quickly, because you have the tests in place, right? So, let’s say you try to fix something and break some other thing, your regression… Even though you don’t have a manual regression testing, because you have the CI/CD in place, it’s gonna run all your Apex tests, it’s gonna run all your LWC, Jest test.

Mohith Shrivastava:
So, it’s gonna make sure that all those tests, where you have essentially added system asserts for your previous business requirements, right? Those pass or fail, you will know that right? So let’s say they fail, you know that, “Oh, no, this is not good code to ship.” You have to go back and fix certain things. So, it makes refactoring a bit easier once you have like unit tests in place. Of course, it is harder, it’s a lot of investment upfront. But once you have like your application, like up and running, then Apex test is gonna make it very easy for you to refactor, and also make sure that you have some quality control in place. And it’s automated for you.

Josh Birk:
Right. Now, bringing things back down to the client, what was your experience with using the Sketch Plugin for LWC?

Mohith Shrivastava:
Oh, that was an interesting learning, actually, for me. I’ll tell you my story as a developer. So, as a developer, I really care about the user interface. That’s my… I don’t know it’s with all the developers or it’s just me. But generally, it’s like, “Okay, get something working, that’s it.” I don’t care about how these forms log, I don’t care about where the button is sort of in place. But my users actually care about it. My users who are actually using the application, they really care about it, and everything actually matters. So, that’s why I’ve learned… And I’ve learned this by working with various designers, I was lucky enough to work with some designers in my past company, and also in Salesforce now. I have a good connection with the design team, especially Adam Doty and the team, the lightning design team, lightning SLDS, Lightning Design System. I recommend everyone to actually go look at Salesforce Lightning Design Systems.

Mohith Shrivastava:
But the idea with the sketch, coming back to the sketch, so what sketch tool allows you to do, is it allows you to prototype something before you actually build. So you know this Josh, that building is the expensive thing, right? If I build something, and then my stakeholders come and say, “Hey, this is not what we wanted.” To refactor and get them what is required, this is an iterative process, and you might spend a lot more time than if you validate your design upfront. And that’s where these tools like Sketch plugins for SLDS plays a huge role because you’re using the same lighting design systems in the base components. And that’s what is offered as a plugin and the sketch tool. So, Sketch is just a tool to design, and it’s not just designed for designers. It’s also for admins and developers. So, what you can do is you can use that tool, you can drag and drop and put your layouts, even mockup your components, again, both in high fidelity, low fidelity, depending on your stakeholders, what they want to see, right?

Mohith Shrivastava:
So you can mock that up, go to your actual users, ask them that, “Hey, if I build something like this, is this what you’re thinking? Is this what you want?” And if they say, “Yeah, this looks exactly like what I was thinking.” So then, with Sketch, you can actually iterate very quickly, because you’re not really building, you’re just dragging and dropping stuff. So, Sketch is interesting to me. That’s why I thought that we need some content on that and I collaborated with the design team, and thanks to them for actually working out with me.

Mohith Shrivastava:
In fact, we had our customers in one of our shows. We had someone, a designer joined from CarMax. And I was interested to actually begin a conversation with the designer on how do they collaborate with developers and admins. Because as a designer also, if you don’t know the limits of the SalesForce, and you don’t know the offerings of the Salesforce, you can design something that might take a lot more time than… You might design something that might be pixel perfect, but with the amount of time that you have, the budget that you have, it might be really not a good activity. So, I wanted to collaborate and see how the team at CarMax actually does it and Brian did a very good job. He’s a designer, senior designer, he did a very good job at explaining me that, “Hey, he has to work in collaboration with the developers, Salesforce developers, and make sure that he produces something that’s really something that they can build.”

Josh Birk:
And that’s our show. Now, before we go, I did ask after Mo his favorite non-technical hobby. And it turns out that like a lot of people these days, he’s getting back in touch with nature.

Mohith Shrivastava:
Yeah, so it’s interesting, my favorite non-technical hobby and must say that during the summers it is playing badminton.

Josh Birk:
Oh, nice.

Mohith Shrivastava:
Yeah, badminton out there. In winters, we don’t get to play that because there’s some wind and also it’s pretty cold out there. So in winters, it’s usually like reading fictional books or watching movies. Sometimes it’s just feeding wild birds. And that’s something that I got interested. I got interested because I see a lot of birds here. We have this feeder, like the bird feeder. We bought a couple of bird feeders and we try with different seeds and see what type of birds are coming. And it’s pleasure to watch them actually. I want to thank Mo for the great conversation information. And as always, thank you for listening. If you’d like learn more about this podcast, head on over to https://developer.salesforce.com/podcast where you can hear all the episodes, see the show notes, and links to your favorite podcast service. Thanks again, and I’ll talk to you next week.

Show Highlights:

Links:

Episode Transcript