Code[ish] logo

Tags

  • Mulesoft
  • APIs
  • integrations
  • databases
  • scripting

71. Linking Data with Mulesoft

Hosted by Becky Jaimes, with guest Dejim Juang.

Data drives every software application, from individual projects to massive enterprise workflows. Whether that information is kept in your database, or someone else's, chances are you'll likely need to unite disparate sources to provide a useful user experience. Mulesoft can help. By providing over 150 connections to databases, third-party APIs, and other services, Mulesoft acts as single integration point between your code and data. Becky Jaimes, a product manager at Salesforce, chats with Dejim Juang, a Master Principal Solutions Engineer at Mulesoft, to talk about the various ways to incorporate Mulesoft in your projects.


Show notes

Becky Jaimes is a product manager at Salesforce interviewing Dejim Juang, Master Principal Solutions Engineer at Mulesoft. Recently, Dejim wrote an article describing how to connect Mulesoft with Heroku Postgres as a new data source. The main function of Mulesoft is to integrate with various SOA, SaaS, and APIs, and provide developers with a single integration point. Rather than writing entirely new data ingestion software from scratch, Mulesoft does the heavy lifting of connecting to data sources and responding back with the requested information.

MuleSoft can be used to build integrations between Salesforce and applications outside of that ecosystem through a drag and drop interface. Some use cases where Mulesoft might not be appropriate include building a BPM tool or managing file transfers. Although Mulesoft certainly has these capabilities, they are too fragile and inefficient to be relied upon heavily. In terms of database connections, you can make RESTful API calls to Mulesoft and have it access information across all of your systems. This is especially useful if your customer data is located in one place and your software data is located somewhere else.

Developers can also write their own code to manipulate the data from disparate sources. They can choose to share their project on the Anypoint Exchange, or continue to use it locally. Although Java is the primary language of choice, there are also scripting choices for JavaScript, Python, .Net, and Ruby. Mulesoft also comes with protections against reporting changes from underlying database migrations, as well as issues with connectivity.

Transcript

Becky: Greetings everybody. My name is Becky Jaimes and I'm a product manager here at Salesforce. I used to be the product manager for Heroku Postgres a year ago and I'm really excited to host this episode because we have with us today Dejim who is part of the MuleSoft team and wrote a really interesting article about the connector from MuleSoft to Heroku Postgres. Dejim, would you like to introduce yourself?

Dejim: So yeah. My name's Dejim Juang. I also go by Jim. I am a Master Principal Solutions Engineer, it's a long title, at MuleSoft. I've been with MuleSoft for about five years.

Becky: We really wanted to talk in particular, kind of like to expand a little bit more about the blog posts that you wrote about the connector between MuleSoft and Heroku Postgres. But before we dive deep into that, let's talk a little bit about MuleSoft. What is MuleSoft?

Dejim: Sure. So MuleSoft is a Salesforce company now. We got purchased about a little over a year and a half ago. And our mission is to connect the world's applications data and devices. So it's a pretty broad mission statement, but our platform allows enterprises to easily connect all their different disparate systems. And it also expose those as API. So there's a lot of different use cases that our platform provides. But initially, when we got our start back in 2006 it was a Mule ESB, so an enterprise service bus. But we've evolved from that point.

Becky: So it was mostly for companies originally it was more for companies trying to bring data from, I don't know, big places from like Oracle and then put them together, help them connect with other databases and to enrich data or? Why did companies use it to begin with? And why do companies use it now?

Dejim: So MuleSoft got its start as an open source platform as an enterprise service bus. And enterprise service bus is a pattern, right? It's a way for systems to send messages to the service bus and then MuleSoft will take that message and pass it to whatever system. So we would go and grab data from a database or go grab data from an enterprise application and route that data based off of rules that you set up within MuleSoft to a destination. Over time though we've evolved past this concept of an enterprise service bus into an integration engine, but also the ability to kind of expose data that you're pulling from systems as APIs and primarily REST APIs today.

Dejim: So yeah. Our main focus today now is around this concept of API like connectivity. But we still have the capability to go back to our roots of routing data, the basic integration patterns of transforming that data, orchestration. So all the old use cases are still applicable. But today we're seeing a lot of use cases, a lot of our customers adopting the platform for exposing data's APIs.

Becky: So it's interesting because Heroku get its start by helping those customers that are actually... it did not start with big enterprise customers, it was the opposite. Heroku started with that person that is sitting in the living room has an idea and he just wants to make it an app really quick, right? So a lot of like the free tier was... that's kind of like the funnel up for a lot of our customers. Somebody is sitting in the living room has an idea for an app, codes it really quick, posts it in Heroku, makes the world know it exists. And it's all on a free tier and then as traffic starts increasing they're able to just like throw resources at it and start paying. Does MuleSoft also have a free tier?

Dejim: We do. Yeah. So that's again going back to our roots, we had an open source. So we have Mule CE, which is our community edition and then Mule enterprise. So we did get our start way back in the day as an open source tooling and similar to Heroku that adoption from kind of the developer word of mouth saying, "Hey. This is a great new tool to build these integrations. Why don't you try it?" And that kind of spread like wildfire. So we now have an enterprise version. And the enterprise version itself, there is actually still a way for you to actually download what we call the Anypoint Studio. And that's a free tool. There's no restrictions in terms of building these integrations. But one of the major benefits of the platform is the ability to build integrations through a drag and drop environment.

Becky: Oh yeah I was just gonna ask that. Is there like a lot of coding that people need to do, to do these connections or is all just drag and drop and you move on?

Dejim: Right. So within the tooling, and again that's one of the major benefits is that drag and drop capability. So instead of developers having to write code and often the use cases like making those connections to the backend systems, we have a set of connectors, a library of connectors close to about 200 now. And it ranges from connectors to APIs but it allows developers to easily drag and drop and click and configure these integration flows that connect different systems. From SAP to Salesforce or Salesforce to SAP. The opportunities of building these integrations are endless.

Becky: What would be common use case for a non-enterprise developer? And also what would be a good use case for enterprise developers. I imagine that for enterprise developers is more like trying to bring their data from big, big resources. Like for example Salesforce or Oracle or wherever you have the data take into a, I don't know, database massage it and pump it back?

Dejim: Right.

Becky: But for the non-enterprise customer, what would be a good, like a common use case?

Dejim: The use cases are applicable still to a basic developer all the way up to an enterprise. At the end of the day, not having to write code and kind of leaving some of this grunt. We're so, the name MuleSoft, that's probably a good segue into why it's called MuleSoft. So our founder, Ross Mason worked in the financial industry and wanted to find a way for developers to not have to do this grunt work. So instead of calling the company donkeysoft, he decided to call it MuleSoft because he considered this integration work, donkey work, right? Or mule work. So the platform itself gives these developers the ability to easily create these integrations without writing that code. So basic developers that are just moving data from a database into a flat file or a flat file into a database, they can use the tool.

Dejim: Even though it's an enterprise grade application, right? These simple use cases are just moving data between systems is there, right. But when you get into the enterprise space, what we're seeing a lot of these days is these companies that need to quickly accelerate the development of the or the agility of the developers, right? Being able to kind of loosely couple the underlying systems by exposing APIs and that's where the enterprise development use cases come into play. But again, where MuleSoft got started in terms of doing that grunt work or that mule work is still capable within the platform and base developers can still use the platform for those use cases.

Becky: And about, what is it like now two years ago, because I believe it was two Dreamforces ago that MuleSoft was recently acquired. And at the time I was working at the Heroku booth at Dreamforce in particular showing data clips, which was a feature that we released around that time. And I'm showing Heroku Connect, I'm doing things in the Salesforce platform, I'm using Heroku Connect to link the data into Heroku Postgres database. And then I'm showing them all the cool things that you can do with Heroku Postgres on heroku.com on the data part of it. And a lot of people came to the booth during that time and said, "Okay. So you have Heroku Connect. You also have MuleSoft. What is the difference? When should I use Heroku Connect and when should I use MuleSoft?"

Dejim: Yeah, so that definitely is a question that comes up often, right? Within the Salesforce community and people that are kind of evaluating different tool sets for integration and also kind of data movement. Heroku Connect is great if you're kind of moving data from Salesforce to Salesforce or you're in the Heroku ecosystem and you're moving into a Postgres database and then you're building applications on top of that, right?

Dejim: MuleSoft is more purpose built for integrations between Salesforce and applications outside of the Salesforce ecosystem, right? So if ServiceNow, SAP, external databases. If you need to connect Salesforce to those platforms or those systems, that's where MuleSoft fits in there. You can also, again, use Heroku Connect and MuleSoft in tandem where that data that you're driving out of Salesforce into Postgres databases, you can expose that again as APIs using MuleSoft and allow that connectivity between that data in the databases, in those different platforms.

Becky: It's not as quote unquote batchy as Heroku Connect. It works more like an API basically.

Dejim: Correct. Correct. Yeah. Instead of scheduled run of moving data between Salesforce into a database, right? MuleSoft can provide this data in real time. So when you build an API within MuleSoft and a user makes a request, it's actually pulling data live, right? It's pulling directly from the Salesforce objects or custom objects and custom fields versus pulling it from data that could be an hour old or a day old sitting inside a Postgres database.

Becky: How about API limits with Salesforce when you use MuleSoft?

Dejim: Heroku Connect does bypass some of those Salesforce limitations. From a MuleSoft standpoint, you can kind of build rate limiting into these APIs to kind of address those API limitations, right? So when you build an API, part of MuleSoft platform is this kind of this API life cycle management. And the tool set provides these API management capabilities where you can actually inject policies to control who can access the underlying data. And this is actually a pretty useful, important part of exposing data, right? Where you can actually include rate limiting or throttling policies to ensure that as you get close to these rate limits, be it Salesforce or any other application, right? You can catch that and ensure that the user has a good experience when they're actually seeing that data from the underlying platform.

Becky: How about if we get into a little bit more of a controversial question here? What is not a good use for MuleSoft?

Dejim: So having a developer background and kind of using MuleSoft. I have this belief of course, that you can build anything on MuleSoft, right? If you want to build it for BPM, you could use MuleSoft to kind of do that, right? But what it's not good for, I would say... BPM, we're not a BPM tool and that's often a question that customers ask us, "Can you replace this BPM system that we have or these BPM business processes?" We don't have BPM built in the platform. The idea with our platform is we're connecting the different systems. So you've got a tool that's has a BPM process, right? If it needs to call out to a different systems, that's where you're going to have MuleSoft kind of sit in between and loosely couple those systems.

Dejim: So later on, if there's a change that underlying system that that BPM tool is calling to, right? We make that transition a lot easier for the developer as well as for the entire ecosystem that that tool is built on. So that's one that we're not a good fit for, right. Being a replacement for BPM, we kind of work alongside of it. And then another one is manage file transfer, right? It's essentially just kind of going back to the old EDI, B2B days of moving files between different systems. We can provide that ability to kind of move files. We have an FTP connector, we have a file connector. You can move files between different systems and you can use MuleSoft for those use cases, but there are more purpose-built MFT tools out there, right? And if that's the specific use case that you're just trying to address, then go with an MFT tool for that.

Becky: So let's now talk a little bit more about what we came to talk here, about the MuleSoft database connector. So why should developers use it?

Dejim: It goes back to kind of just simplifying your workflow, right? Instead of you spending all your time writing custom code, right? Just take one from our library of 150 connectors, drag and drop that into what we call the Mule Canvas and start building those connections. So our database connector, we used to have one for all the different databases out there, but we've essentially combined it into one database connector. And all you need to bring to the database connector in terms of setting up this Mule flow is the JDBC driver for that database. So in this case, for the article, it was just showing the ability to connect to Heroku Postgres without having to write any custom code. You simply just drag and drop the connector into the canvas, you set up the connection properties. So essentially you give it the username, password, the JAR file where that's sitting, and then you test it.

Dejim: And then within the connector we expose different operations. So it varies from connector to connector, right? But for the database connector, it's just your basic database operations, right? Select, insert, delete, update, right? We essentially wrap those operations and expose them as different connector operations that you can drag and drop in and perform those transformations on the data or on the database itself. But it allows those developers to move a lot faster, right? Instead of spending all that time writing custom code, it gives them the ability to easily just drag and drop and click and configure those specific use cases.

Becky: Is the MuleSoft database connector part of the free for those developers that are just testing things? Will they find it in the non enterprise MuleSoft?

Dejim: It is. So we do have three different tiers of connectors out there. We've got select, we've got premium, and then we've got community. So premium of course generally has additional fee. The select ones are ones that we've built internally that we provide to our customers and those come at no cost, right? So as you're playing around with the tool, right? Playing around with Anypoint Studio, you can download those into studio or we provide some of them out of the box and you can use those within your projects, free of charge. And then we also have community connectors. These are connectors that our community have built and published into what we call the exchange. But this concept of reuse, right? Gives users and our developers a way to kind of contribute back to the community, right? So these connectors, they can publish those into the exchange and then other developers can take those connectors into their projects and start connecting. So-

Becky: And the Heroku Postgres could be found on the free tier?

Dejim: We don't have a Heroku Postgres connector per se, but you can use the database connector to connect to Heroku Postgres. So if customers have Postgres sitting in other platforms, right. Or other cloud platforms, they can use the database connector to connect to those.

Becky: So the MuleSoft database connector is in one of those tiers?

Dejim: It is, yeah. It's in the select here.

Becky: Oh I see. So if we want to use Heroku Postgres with the MuleSoft database connector, it has to be in the select tier, not in the free tier?

Dejim: Well, the database connector just exist in the select tier. So yeah. It comes with the platform and you can use it for your development.

Becky: Yeah. So for those folks that are going to try it, what would be the best problem to get started with that if I have a problem to be solved, what type of problems should I pick?

Dejim: So one benefit of what we call the Anypoint exchange is that it actually comes with different templates and different examples. So we have a lot of common use cases and scenarios in there that other customers have run into. So ETL use cases, right? Being able to kind of just connect to a database and then move that into Salesforce instead of developer having to go and rewrite that whole integration flow, they can actually download that template or example into studio, configure the credentials for the database, configure the credentials for Salesforce and be up and running quickly.

Dejim: So ETL is one use common use case, exposing APIs. So when you build an API, a RESTful API within the platform using our API designer, the other part of that is the implementation where you actually connect it back to the database. So within the flows that you build within studio, that's where you're going to drag and drop in the database select operation into the flow. You can also build in business logic into these flows where if you want to grab the data from a Postgres database and from ServiceNow and from SAP you can do so within the flow and then concatenate all information into one response that you send back to the user.

Becky: What is a common mix that you've seen for these enterprise customers to bring data from multiple sources into one response? What is a combination that you've seen often?

Dejim: So one common mix, right, is like order history or customer information, right? So oftentimes in the enterprise level their customer data is sitting in a lot of different spirit systems, right? They've got customer data in Salesforce, they've got customer order history or products that they own within SAP. The ability for MuleSoft to go in there and grab data related to that customer from both systems and expose that in a new API is one of the major benefits. If you think about the code that would need to be kind of built out to kind of expose that, with MuleSoft once you start building these APIs and connecting all the different systems with the connector, you'll kind of see some of the return that you'll get as a developer, right?

Dejim: You're not spending all that time writing code and testing it. You're simply using our connectors to easily go and connect to those systems, grab the data, use the transformation tool called DataWeave within our application, and then tie that together into a response that you want to send back to the customer. But the possibilities are endless within the platform.

Becky: And how about, again, as early, how about limitations but as it relates to the connector?

Dejim: Yeah. So the limitations generally lie within the endpoints that we're wrapping. So our connectors either wrap SDKs, right? So say for example, like the Amazon Web Services S3 connector or SNS or SQS. We're essentially wrapping the Amazon SDKs with the Java libraries. And then we also have other connectors that wrap different APIs out there, right? REST API, SOAP APIs and expose those in a way where the developer doesn't have to be concerned about the underlying code around how to manage that specific API. For the database connector, the limitation generally lies within the JDBC connector itself, right? So we're wrapping essentially the JDBC driver for that specific database. In general that's a Type 4 connector, right? Where essentially it's actually translating a request that's going to be sent down to that database. So if there's limitations within that JDBC driver, that's the limitation that the developer will see.

Dejim: And if those limitations are kind of showstopping, it doesn't stop the developer there, right. One of the major benefits of MuleSoft, again, is also that it's not a black box. They can, if they do run into those limitations, they can actually write their own Java code and embed that into either a connector, right? They can write their own connector and publish that into the exchange or they can write their own Java code and incorporate that into the project and then have that be instantiated and called within the Mule flow. And then also we have connectors for .Net. So if you're in the Microsoft world and you want to invoke operations within DLLs, you can do so within the application. And then we also have a scripting component that allows developers to write code in JavaScript, Python or Ruby and incorporate that directly into the flow as well.

Becky: What is the most popular language that you've seen when it comes down to this database and connectors? I'm curious.

Dejim: Java is the most common. I mean, the platform itself is built on Java. The Mule runtime itself doesn't require its own app server. It essentially just requires a JVM. So most developers that come to the platform, they are coming from the Java world. But we do have a lot of customers that are also in the .Net world and essentially leveraging the platform to kind of connect their different systems, right? So again, think of us as kind of the plumbing between your different systems, right? We provide that connectivity between different platforms.

Becky: How do the connectors work after somebody runs a new migration under database? Like if they changed the schema or something like that, how does the connector react?

Dejim: Pretty much the same as if you're writing the code, right? So if they've changed the schema or they've changed the column name, it'll throw an error back to the flow to say, "Hey, there's-"

Becky: Please update this.

Dejim: Yeah. Please update this. If you've built kind of just a general ETL flow, then Mule itself, there's also the ability to kind of put in exception strategies where if the destination is down or it spits back an error saying that the schema has changed, right? You can take the data and route it to a different location, right? Drop it into a message queue or dead letter queue to say, "Hey, this needs to be addressed."

Becky: Does it back play? Does the connect back play the data? Let's say that there was an error, right? Somebody did a migration in the schema or something, there was an error. It threw the error, but data kept coming. Does it have the ability to back play that data later once the problem is resolved?

Dejim: Out of the box, no. But you can build in kind of that back play functionality, right? So if you've built your flow out to kind of address those errors that you can potentially catch, that's where you can kind of route that data into a different data store to be processed later.

Becky: Is there a guide that you can point people to go to other than the blog posts that we would probably link on the resources here. Is there any other thing that you recommend people to take a look at before testing the database connector?

Dejim: Our docs are probably the best source for running through and kind of finding out more about the platform. So docs.mulesoft.com. Our training website is actually has a lot of great content there as well. So training.mulesoft.com. There's some free courses that you can kind of run through that give you the full run through the entire platform from downloading Studio, setting the project, building an API, all that's enabled through the training courses. So there's a lot of content out there. And then StackOverflow has a pretty good community of mule developers that are always helping out enter answer questions as well.

Becky: Going back to the integration with Heroku, so we've talked a lot about the Heroku Postgres integration, but is there other ways also to integrate with, for example, the other managed data services that Heroku offers like Kafka and Redis?

Dejim: Yeah. Yeah, yeah. So again, Postgres is just kind of one different source or destination that MuleSoft can interact with. The two that you kind of said there are Kafka and Redis. I've got another post that kind of talks about how to connect to Heroku Kafka over SSL. Redis I haven't played around with as well, but we do have a Redis connector. So check out the exchange. Just type in kind of a specific platform. And if it doesn't have a connector, we do have generic ones for HTTP. So if you want to make a rest request, we do have one for SOAP APIs called the web service consumer and we also have other generic connectors, right? If you want to build your own connector to connect to those different platforms. But in relation to Heroku, the different add ons that you can add onto your system or your projects, if there is an API or an SDK that's wrapped around those different systems, MuleSoft can easily connect to them.

Becky: As we were talking, you're so passionate about this topic and I'm digging the passion. But it made me wonder how did you land at MuleSoft?

Dejim: Oh, so I actually came from the app space. I used to be selling CRM and kind of implementing CRM. Did a year as a product manager and then a friend came aboard to MuleSoft and was like, "Hey, this is a great new company. They're doing these amazing things." And I was like, with my curiosity I went and downloaded the tool set and I started playing around with it. And that's one of the great things about MuleSoft is that they do provide the ability for you to kind of play around with a tool set before you actually kind of go all in, right?

Dejim: So the studio itself, free download built on Eclipse. Once you download that and you start looking to the connectors, the possibilities are endless, right? It's kind of like Lego building blocks where you have all these different blocks and then you can... the sky... the opportunity's endless in terms of building whatever you want, connections, APIs. So just started connecting different systems and thought back to my years as a developer and as a product manager, having something like this speed up the development of my teams would have been great when I was in that role. I was like, "Sign me up. Let's start working in MuleSoft." And I have been there for about five years now.

Becky: So after the acquisition, are you hella rich?

Dejim: Hella rich in knowledge. One of the key things about the platform is that from the app space generally you're of tied to just a single platform, right? You're learning all the ins and outs, the capabilities that provides. But with MuleSoft, I mean, I am touching SAP and I'm learning about IDocs and mapping. So I'm touching Salesforce and I'm learning about objects and all the different pieces like Heroku and Marketing Cloud and Commerce Cloud, right? And I'm interacting with different databases and new technologies. I mean, that's where I'm really excited with the platform and I think for the foreseeable future is that as we start hearing about new technologies or new kind of ways to connect.

Dejim: So AsyncAPI is a pretty new one that's kind of popping up right now around describing an asynchronous connection, right? Between different systems. So like Kafka and streaming and all that stuff. That's one that we're starting to get into a little bit. IOT is another great realm that we're talking about, talking with customers with the growth of AWS and Azure and Google Cloud, right. I mean, just connecting those different systems with back office, with on-prem, MuleSoft gives you that ability.

Becky: Right. Briefly, when we were preparing for this you mentioned about you build some stuff for serverless functions and that's going to be really interesting because we're also building some stuff for serverless functions for our Salesforce customers. That should be a pretty nice synergy of everything.

Dejim: Yeah. It will be. The serverless has definitely taken off in terms of developer adoption where they can run these specific functions and not be paying for the overhead of just if it's runoff, right? They're not paying for that usage, right? So we do have customers that are kind of investigating the platform. I built an example that allows us to proxy Lambda, right? So an AWS Lambda where you can kind of control the ingress of that request down to the backend, right? But it gives you that visibility with the platform to visually understand who's making calls to these backend Lambdas and how much data they're getting out of these systems, right? But with API management sitting on top of serverless, right? It gives you a whole realm of new kind of control and visibility into that world of serverless. Where we're seeing a lot of adoption of MuleSoft is this whole API, right? API led connectivity is a phrase you'll hear occasionally.

Dejim: But the concept around that is that instead of building point to point integrations where you're just connecting a database to Salesforce, build APIs around that database, right? And expose them in a way that it allows your developers to make changes quickly. So if you are starting on Postgres, you're starting on SQL server or MySQL, when you build this API, you're loosely coupling the underlying data, right? From the consumer to the accessing that data down below. So if at some point, you're starting to scale out and the amount of requests coming to that APIs grows and you're not able to scale out, right? You can switch to a new platform and the consumer doesn't have to know of that change, right? They are tied to the contract that you've defined in the API and they'll keep calling that. But you as a developer can go and quickly change that database, right? Or change the connection to a different system. And that's the main benefit of this API led where you're allowing this agility of your IT to move faster, right?

Becky: Yeah. Like you can scale the business as... it's kind of like the whole idea of Heroku. You start with an idea and a free resource and as it starts scaling, you just go into the dashboard and click.

Dejim: Right. Yeah, yeah. Making changes quickly as a developer and not being tied down with all the underlying code. So in the past with a point to point, if an error occurred with a database or the code itself, you would have to bring down the entire integration system. And that's, I guess another good segue into MuleSoft is our scalability, right? We can be deployed in the cloud in what we call CloudHub, which is our integration platform as a service or on premise. And traditional integration platforms out there, your integrations, your point to point integrations ran on a single server. So if that whole server went down, every integration that you had, there might be some disaster recovery and some HA in there, right?

Dejim: But that single integration could affect all the other integrations that you have. MuleSoft, because we are running in the cloud, we have the ability to scale both horizontally and vertically. So your applications, when you deploy them into CloudHub, they're actually running isolated from every everything else, right? From customers, from your own projects. They're running in their own instance in the cloud. And if something goes on with that, if some errors occur, it won't bring down other integrations that you have running within your ecosystem.

Becky: Yeah. It is not a trivial problem to solve and a much needed one too so...

Dejim: Yeah. And it goes back. So that concept of that design, right? It goes back to that serverless concept, right? Where you've got this single serverless endpoint that's handling this specific use case, right? And it's isolated from all the other ones. So you can kind of look at Mule as in some ways a serverless API, right? If you build an API with a platform and deploy that, it's running and handling that function, but it doesn't have the benefits of the serverless where it's going to spin it down after it's done, right? It does continuously run so it does give you the benefit of building ETL processes or other use cases into the platform itself.

Becky: Right. Well, it was lovely to have you. Thank you so much for sharing everything.

Dejim: Yes. Thank you Becky, it was very nice meeting you and hopefully we can meet in person.

Becky: Yes I know.

Dejim: Talk about some other connectivity options with MuleSoft and the Heroku system.

About code[ish]

A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.

Hosted by

Avatar

Becky Jaimes

Product Manager, Heroku

Incurable optimist. Surf wanderer. Data Aficionado. Colombian to the bone. Eats soup for breakfast.

With guests

Avatar

Dejim Juang

Master Principal Solution Engineer, MuleSoft, a Salesforce company

Dejim is constantly trying to figure out how to connect the world’s apps, data, & devices. When not working, he travels the world with his family.

More episodes from Code[ish]