Emmett Chen-Ran is an Associate Product Manager here at Salesforce. Today I’m sitting down to talk with him about the upcoming Pub/Sub API. We also discuss what will be required from an infrastructure perspective to make it work and work without breaking things.

The Pub/Sub API is a brand new API for developers to allow them to do bidirectional streaming events.  Based on gRPC, it offers new features and has an updated messaging protocol from traditional clients like CometD. Currently in pilot, tune in to find out how you can leverage this API for your solutions.

Show Highlights:

  • What drew Emmett to pursue the people-centric side of development.
  • How the Associate Product Management program works.
  • What Apache Kafka is and how Salesforce is leveraging it.
  • Why we’re expanding the infrastructure on Salesforce’s Streaming API.
  • How to move tons of events to a new runtime without a failure.
  • What the Pub/Sub API is and the benefits it brings.
  • Why gRPC is more efficient for developers.
  • How the Pub/Sub API works with and complements CometD.
  • Resources to help you learn about and start using this new API.

Links:

Episode Transcript

Emmett Chen-Ran:
I knew from a pretty young age, in high school, that I was interested in computing and technology

Josh Birk:
That is Emmett Chen-Ran, an associate product manager here at Salesforce. I’m Josh Birk, your host of the Salesforce developer podcast. And here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Emmett about the upcoming new pubsub API, what we’re doing from an infrastructure point of view to make that work. And then what are the details the developers will want to know about utilizing that API. But as usual, we start back with his early years.

Emmett Chen-Ran:
I sort of quickly realized that, or not so quickly I guess; I had done four software engineering internships before I realized that perhaps I wanted to go a route that was more people centric and more collaborative, and a little distanced from the code, and more closer to the humanity aspect.

Josh Birk:
That’s interesting. So was there an event that kind of pushed you in that direction, or just sort of your relationship with code and development in general?

Emmett Chen-Ran:
There was definitely a time during one of the summer internships that I did where I went a whole day, so as a software engineering intern at the time, and I went a whole day without speaking to a single soul, and everything was over slack and everything was tight. And at the end of the day, I was sort of like, this is no way to live. I need to like see and touch and feel other people near me.

Josh Birk:
So the pandemic must be driving you crazy?

Emmett Chen-Ran:
Well, yes and no. Because definitely I think so many things have become so much more accessible for everyone in various ways, but yeah, definitely missing out on the social aspect. But now again, things are opening back up, so it’s not so flexible anymore.

Josh Birk:
Are you going into the tar?

Emmett Chen-Ran:
We’ll see. I don’t even know what’s open right now.

Josh Birk:
Oh, okay. Gotcha. Well, speaking of that, how did you get introduced to Salesforce?

Emmett Chen-Ran:
Yeah, I met Salesforce at a recruiting fair at the “Out For Undergrad Tech Conference”, which is a tech conference for LGBTQ undergrad students and Salesforce had a recruiting booth there, met them, was introduced to the APM program that was sort of my first introduction to product management actually. And it was the only APM or product management position that I applied to that fall, because I was still thinking I would do software engineering, and somehow I got the position, and the rest is history.

Josh Birk:
Got it. So let’s dig into that product, or not the product, but I’m trying to think of the right term, but the associate product management as a specific kind of job profile that we have at Salesforce. Can you tell me a little bit more about that?

Emmett Chen-Ran:
Yeah. The APM program at Salesforce is modeled after the Google APM program, which our very own Brett Taylor graduated from. And it’s sort of a hot trend that has been taking a lot of tech companies by storm in recent years, in that they want to build this pipeline from undergrad to being a full-time PM. And so most APM programs take new grads or soon to be new grads, and put them through a sort of two year ramp up process where you rotate between multiple teams within the company, sort of get a breadth first exposure to the company. Other people have called it, sort of getting an MBA in the company. And at the end of the two years, sensibly, you are prepared to do anything.

Josh Birk:
Gotcha. Because it’s kind of like a rotational model, right? Like right now you’re working on it, working with the API team, but then you, we have either worked with somebody before you’re going to move on to something else?

Emmett Chen-Ran:
Right, exactly. So from last July to this March, I was on Sales Cloud, which is a totally different world and platform, by the way.

Josh Birk:
Yes.

Emmett Chen-Ran:
So I’m currently in the middle of my second rotation and I’ll be doing a final rotation, in who knows where.

Josh Birk:
Got it. I was going to say, any guesses as to where that will be, or do they just kind of provide you with a now and in the near future?

Emmett Chen-Ran:
Oh man. I feel like so many people in the program are doing Trailhead now. Like it just feels like all paths lead to Trailhead.

Josh Birk:
Yeah. Yeah. I kind of feel that history a little bit. That’s, that’s for sure. All right. Well, let’s talk more about what you are working on now, or want to talk about the pub/sub API. But it kind of sounds like before we talk about that, we want to talk a little bit about laying the groundwork, like when it comes to the event bus itself.

Emmett Chen-Ran:
Sure.

Josh Birk:
So first of all, tell me what a Apache Kafka is and how is Salesforce leveraging that?

Emmett Chen-Ran:
So Apache Kafka is an open source technology that exists outside of Salesforce. And we have our own instance of it that we built in-house that basically serves as the groundwork for our venting system. Kafka is where all our events are stored. And so the customer doesn’t necessarily need to worry about that, but it’s a critical piece of the event driven architecture that we offer to customers.

Josh Birk:
Gotcha. So it’s what’s driving our current streaming API and what people are kind of doing for this kind of thing, but there’s, it sounds like there’s sign of a push to put more infrastructure, or different infrastructure, to it. What’s driving that kind of need?

Emmett Chen-Ran:
Yeah, I think a lot of it comes from first the desire to stay on top of the market and on top of industries trends. In that we want to show customers that we’re not relying on infrastructure that was built like years and years ago. This is an active area of development for us, which is why we’re building out a new runtime, a new API. And with all those things that we’re building out, come increased scale, increased performance, better load balancing for our internal infrastructure, and with that better and smoother experiences for customers.

Josh Birk:
Gotcha. And it sounds like we’re trying to kind of, I don’t know if divorce is the right word, but let me put it this way: it sounds like we’re trying to put the new infrastructure up on its own stack and its own iron, and it’s not going to be running dependent on what we think of like as our pod iron infrastructure?

Emmett Chen-Ran:
Yeah, we are sort of trying to make a distinction between the new infrastructure we’re building out off core, and the existing core infrastructures. So if people are familiar with this, the core is sort of the OG Salesforce tech stack, like sales service, that kind of stuff. And with the expanding infrastructure and product suite that we’re offering, of course we have to build off core a little bit and expand into new horizons and all of that. So the new runtime that we’re building is off core and we’ll take some of the load that is solely on core right now, and sort of shoulder that burden so that we have multiple runtimes executing, delivering, publishing events.

Josh Birk:
Gotcha. And are other properties like MuleSoft and Tablo play into this at all?

Emmett Chen-Ran:
They definitely play a part. I would say MuleSoft sort of lets you handle your holistic integration fabric, in that you can set up connectors or integrations and just sort of get a lay of the land and get a really bird’s eye view of how all your integrations stand. And our APIs, the platform APIs, are for off platform integration for sort of system to system integration. So they’re serving slightly different use cases, but they’re definitely a part of the overall picture.

Josh Birk:
Gotcha. So it’s sort of like it has any other random no doT.js client is going to get benefits from this, so will our partners as well?

Emmett Chen-Ran:
Yeah. I’d say so.

Josh Birk:
Nice. So there’s a great blog post by, I believe your boss Tyson Reed? I think that might be his name?

Emmett Chen-Ran:
Yup. The man, the myth, the legend.

Josh Birk:
The man himself. And I loved this question. We’ll point to this blog post in the show notes. I love this question in the middle of it. How do we move billions of events to a new run time without a failure?

Emmett Chen-Ran:
Carefully. I will say we are still developing the new runtime.

Josh Birk:
Okay.

Emmett Chen-Ran:
We are starting, we’re going to be starting to move some of that traffic over, but currently it’s very much in development. We’re doing a ton of performance testing. We’re simulating all these use cases so that when we do live production traffic in the near end time, customers won’t even feel a difference. It’ll sort of just be known to us behind the scenes and it will be reflected in a greater number, or greater heights, that all customers can scale to. So it wouldn’t necessarily be that any given customer can suddenly do like a ton more things that they could before, but it’ll be reflected in the overall landscape of how all customers are doing.

Josh Birk:
Got it. And to be specific on this part that we’re talking about, no action on the customer, it’s just eventually net benefit for them?

Emmett Chen-Ran:
Yeah, exactly. And so, like you mentioned in the blog post, if people are interested, feel free to read more in the blog post, a key component that we’re investing a lot of time into is that a probing, which just means sort of pretending to burden the system with a lot of events or traffic and just stress testing it and making sure that we can handle any sort of traffic pattern or spike that customers in production throw at us.

Josh Birk:
Interesting. So you can build out the iron, set it up, and then basically, I mean, that’s a very specific term. Am I simplifying by saying that you’re basically flooding it with fake data? Or is it more complicated than that?

Emmett Chen-Ran:
I would say that’s the gist of it. Yeah.

Josh Birk:
Okay. Okay. And I love how much fake data has become a trend on the podcast who knew how much, how useful fake data could actually be. Okay. So let’s move on to the API itself. Now to be clear, the pub/sub API, it’s a brand new API, right?

Emmett Chen-Ran:
Yeah. It’s never before seen.

Josh Birk:
Okay. And what’s effectively the elevator pitch for?

Emmett Chen-Ran:
The elevator pitch, it’s that, so it’s called the pub/sub API, and it’s named that way because you can pub and sub with this one API. So how the landscape stands today is that you need to use multiple APIs if you want to publish and subscribe to events. And so that ends up being increased maintenance time for developers, increase onboarding time, because they have to learn how to interact with these different APIs. And usually a non-insignificant amount of time is spent developing the subscriber client in particular. And that’s because it uses a specialized protocol that not many developers have had experience with before. And there’s also not a ton of great online examples or online developers support for that protocol. But with the new pub/sub API, it’s a GRPC based API, which is, stands for Google Remote Procedure Call. And it’s this new mostly used by enterprises, but definitely used across the board.

Emmett Chen-Ran:
And it’s great for enterprise microservices in particular, because it has one: a ton of online developer support and examples. So for example, with my former software engineering background, I took the Liberty of writing a little demo using the API and I’m not a great programmer, so I had to Google a lot of things. And along the way, every single thing that I encountered already had some sort of stack overflow equivalent answer to that. And a lot of these answers were provided by the Google developers themselves. So it just really stands to show like how active and thriving the online developer community is around this API protocol, which spells success for our customers.

Josh Birk:
Got it. First of all, all great programmers Google a lot of things. I think some might even argue that’s part of what makes them great programmers. An ongoing in-joke in the show is that this stack exchange is sort of my IDE. So you’re in fine company. You’re in fine company. Well, so that part’s pretty interesting to me though. Especially every implementation of, well, I don’t know about every, but like 99% of every implementation I’ve ever done that’s been a streaming based solution, has used CometD. And so this kind of gets rid of CometD, and then it’s replacing it with what? Or are we just now in the world of like web standards where we don’t need that shim layer anymore?

Emmett Chen-Ran:
I would say don’t throw out your CometD integration if you like CometD. We’re not deprecating CometD by any means. It’s sort of just a more consolidated, streamlined, way of doing the same functionality that the CometD client used to do.

Josh Birk:
Okay.

Emmett Chen-Ran:
So it’s sort of, the way that my manager Tyson put it is: some people like chocolate, some people like vanilla, and we’re offering now the mix of chocolate and vanilla as a third flavor.

Josh Birk:
Got it.

Emmett Chen-Ran:
So yeah, no need to kick CometD to the curb if it’s working for you. And I would say the difference with the pub/sub API being GRPC base is that it’s a standardized API protocol, right? So one of the benefits that customers could stand to reap from using this API is there are developer tools out there that let you declaratively generate these API calls. So hypothetically, you could have your developers use click and drag tools to generate the calls and then spend their time writing the more complex logic around their integration.

Josh Birk:
Interesting. So are we talking like a swagger tool, or is it a swagger tool that’s effectively creating that handshake layer?

Emmett Chen-Ran:
It’s, I would say from what I’ve seen, the declarative tools that you could use are similar to Postman.

Josh Birk:
Okay.

Emmett Chen-Ran:
Which does declarative rest and so API generation, and there isn’t like as official of an equivalent as Postman right now for GRPC, but there are definitely multiple GitHub repos that I saw.

Josh Birk:
Okay. So I think there’s something else about GRPC that makes it more efficient. As a JavaScript developer I’m kind of immersed in the world of JSON. What does GRPC do for messaging, and how does that make it more efficient?

Emmett Chen-Ran:
Yeah, GRPC’s payload is Protobuf, which is serialized and deserialized every time it sends or receives a message. And this Protobuf format is highly lightweight and super compact. So it actually ends up being seven to 10 times faster than rest APIs, which use JSON. So if you’re used to working with JSON, you’ll be like, “wow, this is blazingly fast”.

Josh Birk:
I mean, because even in internet terms, that’s a visible increase in speed.

Emmett Chen-Ran:
Exactly.

Josh Birk:
Nice. And I guess that would be another reason why if I’ve got my existing rest API, I’ve got my existing implementations, that’s fine, but there’s yet another reason to, for future implementations, to possibly start looking at the pub/sub API and stuff.

Emmett Chen-Ran:
For sure. And I really think that GRPC is going to just get bigger. Like right now it’s very much confined to sort of enterprise microservice circles, but being that it’s built on HDB too, being that it has such better performance, and being that it’s an active area of development for so many developers, I have no doubt that more and more APIs will harken to GRPC.

Josh Birk:
Okay, so I have to ask this clearly, even though I’m pretty certain you just covered it in multiple ways, but it’s always going to be a question. So with this new API, we are not deprecating the streaming API, we’re not dropping support for the streaming API, streaming is the vanilla next to your chocolate?

Emmett Chen-Ran:
It is, exactly.

Josh Birk:
Okay, okay.

Emmett Chen-Ran:
And it’s, everyone has their own strokes and their own preferences, and some people love CometD, I’m sure. And some people are going to love the GRPC API.

Josh Birk:
Yeah. I don’t know if I ever loved CometD?

Emmett Chen-Ran:
There’s got to be someone out there.

Josh Birk:
There’s got to be someone out there. I mean, to give it credit, there was definitely a period of time where it’s like, that was it. Like you really didn’t, if you wanted to do real time, near real time, especially if you’re doing it like in JavaScript and to go back to the old days, a visual force page that wanted to give you an alert pop up because some account had a status change, like CometD was really the only way to get that solution done.

Emmett Chen-Ran:
Yeah. And I’ll say that CometD is still really good for these sort of browser notification or alerts, that kind of use case. Whereas, I’d say the new pub/sub API, because it’s more, one of the really cool features it has is that it has bi-directional streaming, which allows events to be published and subscribed to, in any order the client wishes. And so, the client could publish an event, receive three events, publish another event, receive 10 events. It really sets its own path for what pattern of publishing and subscribing it wants to take. And this channel is a bi-directional channel in that both the server and the client can send or receive whatever they want in whatever order they want, while GRPC preserves the order of the stream of the messages.

Josh Birk:
Okay, so I have so many follow questions, sir. First one, that sounds, so correct me if I’m wrong, CometD uses, you probably know the term and I’m blanking on it, but it’s like a long handshake protocol, right? Like it asks the streaming API, it says hello, it tells it what it wants to listen to, it starts to listen. And then the streaming API asks every now and then, are you still there? And if it’s still there, then it will still continue to do the protocol, but it’s kind of, it’s kind of a loose connection between the API and the client. Is that kind of technically accurate?

Emmett Chen-Ran:
Yeah. And I would say it’s also up to, it depends on each customer’s individual use case. Some customers might want their subscriber client to come online, say once a day, and retrieve all the 30,000 events that have been piling up.

Josh Birk:
Right.

Emmett Chen-Ran:
Other customers might want their clients to stay online all day and receive them in real time. And what I was getting at with the comparison before is that where CometD is more optimal for these sort of browser alerts or notifications, the pub/sub API is more geared towards system to system communication. So if you want Salesforce to talk to AWS, or if you want to connect like Workday to some other system, the pub/sub API is really suited for these types of use cases.

Josh Birk:
So let’s dig into details there. And I think that was a really good distinction to make because CometD, browser notifications, it’s sort of its bread and butter. Especially when it comes to that scenario we were talking about where it’s like, I want the first 30, and then the next 10, and this kind of complicated ordering of events, what’s a real-world use case where the pub/sub API is going to be 100% the best solution for that?

Emmett Chen-Ran:
So in the demo that I just built out, a really good use case would be inventory replication across systems. So, let’s say you have an inventory system outside of Salesforce that needs to be kept updated with your opportunities inside Salesforce. The demo that I made tracks change data capture events.

Josh Birk:
Okay.

Emmett Chen-Ran:
So for those who don’t know, change data capture events are events generated by Salesforce and published by Salesforce, when any object that you’re interested in has a change made to it. So, let’s say I wanted to track the opportunity object. If I tracked the opportunity object in my setup, then every time an opportunity is created, modified, or deleted, Salesforce will publish a CDC event under the opportunity data change stream. And then I can consume that event somewhere else. So if I have an inventory system outside of Salesforce that needs to stay up to date on what opportunities have just closed inside Salesforce, I could listen, using the pub/sub API, I could listen for that CDC event, and as soon as the order is confirmed and closed inside Salesforce, my inventory system outside Salesforce can then replicate that order in my system so that all my systems are up to date.

Josh Birk:
Got it. And it’s not, when we think of things like CometD, it’s a very one doorbell, get the door, just kind of one-off kind of response. So that inventory or system you’re talking about can not only get, it’s not getting an object or an event, it can get multiple objects based on an event and in the correct order?

Emmett Chen-Ran:
Yes. And what’s even better with the pub/sub API is if that inventory system needs to send something back to Salesforce, you can do that now with the same API. So let’s say it takes in this new order because a new opportunity has just closed in Salesforce. It replicates that order in its own system, and let’s say it calculates an estimated delivery date for that order. If we want that estimated delivery date back in Salesforce, the external inventory system can publish its own event, send it back to Salesforce, and then Salesforce can use the data in the payload of that event to update itself.

Josh Birk:
Got it. So going back to the bi-directional model, if your system, if it’s a system of questions and answers that are in multiple order, the pub/sub API will just handle it.

Emmett Chen-Ran:
Exactly.

Josh Birk:
Got it. Nice. Well, let’s talk a little bit more about implementation, CometD’s JavaScript, but there’s also Java. I think one brave hearted fool might’ve tried an Apex Solution at one point, but I don’t know if it ever works. What kind of languages support GRPC out of the gate?

Emmett Chen-Ran:
Officially GRPC is supported in 11 languages. And these are some really common like bread and butter languages like: Ruby, Java, Python, Go, there’s C++, C, there’s a ton. And I’m sure that you, and everyone listening, has worked with at least one of them. And unofficially, there’s developer support for even more languages. So you can really go and run wild to your heart’s content with GRPC.

Josh Birk:
We can Google things to get more information. Are there any other resources you recommend for learning about how to use this in general?

Emmett Chen-Ran:
For sure. We have two published blog posts now about the new API. So one that we referenced earlier hosted by medium, and then another one that was just published on Tuesday on the Salesforce developers blog. So both of those are about the event bus, but also about the pub/sub API.

Josh Birk:
Okay.

Emmett Chen-Ran:
And there’s also a demo on the TDX website for anyone that attended TDX or anyone who has yet to sign up, it’s on there. You just have to log in to the conference, which is free and click, I think, two things that will lead you to the demo recording. And lastly, if you’re really interested and you want to play around with the API, we had the pilot launching in August, so you can just contact your AE, get them to sign you up for the pilot, and you can start tinkering around with the API yourself.

Josh Birk:
Got it. Is there a specific date for that or TBD in August?

Emmett Chen-Ran:
Sometime in August. Yeah.

Josh Birk:
A forward looking statement. You are a learning Salesforce, my friend, you’re a learning Salesforce. And that’s our show. Now in the show notes, we will have links to those various blog posts. But remember that if you want to be in the pilot, reach out to your AE. Now, before we go, I did ask after Emmet’s favorite non-technical hobby.

Emmett Chen-Ran:
I produce shows outside of work.

Josh Birk:
Really?

Emmett Chen-Ran:
So yeah, I really love the event and theater production. And so I work with this organization called GAPA, which stands for GLBTQ Asian Pacific Alliance. It’s a sort of queer Asian social group in the bay. And we put on a pageant every year called Runway and I am the producer for Runway. So it’s, this is the show that I was telling you about the other day, Josh, where you’re like, “Dreamforce is two months away”. I’m like, “yeah, my show is also two months away”. I think it might be like consecutive weekends in September. So I’m very much feeling the heat of this deadline looming.

Josh Birk:
Nice. Nice. Yeah. I think one of the old jokes I used to say was like in event production, two months is basically tomorrow.

Emmett Chen-Ran:
Exactly, exactly.

Josh Birk:
I want to thank Emmet for the great conversation and information, and as always, I want to thank you for listening. Now, if you want to learn more about the show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast services. We are out on all major podcast services, as well as available in Apple, Google and smart devices. Thanks again, everybody. And I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.