S11E02 HTTP Requests (Elixir V. JavaScript) with Yordis Prieto & Stephen Chudleigh
Track 1: Welcome to another episode of Elixir Wizards. A podcast brought to you by Smart Logic, a custom web and mobile development shop. This is Season 11, where we're branching out from Elixir to compare notes with experts from other communities.
Owen: Hey everyone, I'm Owen Bickford, senior developer at SmartLogic,
Sundi: And I'm Sundi Myint, engineering manager at cars. com.
Owen: we are your host for today's episode. Today we're joined by Yordis Prieto, founder of Straw Hat, polyglot developer, and contributor to the Elixir Tesla HTTP client library. We're also joined by SmartLogic's own Stephen Chudleigh, who has a background in Rails and JavaScript. The topic for today's episode is making HTTP requests.
So hello, Yordis and Stephen. How are you?
Yordis: it going?
Owen: Awesome. So I think we're all writing Elixir these days, but we're coming from different backgrounds. I think it'd be nice to start with how we came to be Elixir developers. We'll start with Yordis. What's your path to Elixir?
Yordis: Before Elixir I was in the Rail stack and Node. js for a long time. Then one day I was just watching Twitch and saw somebody doing Phoenix. That was in 2016, 17 I believe, long time ago. And got my curiosity speaking about performance and fast and processes and I got into study Elixir and see what, what was done there.
And I'm falling in love with it and never looked back since then.
Owen: And then Steven, how about you?
Stephen: Yeah. So I've been a full stack developer, a web developer, for coming on two decades now. So kind of a journey, man. I've been through a number of different startups and mostly in the Rails space. Having been in the rails community for a while, I started to notice that a lot of developers were starting to move over to elixir and, started to read up on Phoenix and stuff.
I heard about Erlang. Quite a while before, but, I looked at some of the syntax, it kind of scared me off. I got a little bit intimidated, so, I held off, and then I saw that Elixir was pretty close to Ruby, and it felt pretty comfortable, so I just decided to try it out on a side project, and kind of fell in love, and went forward from there.
Sundi: Cool. Thank you both. Yordis, I did actually really want to ask you, your company name is Straw Hat. How did you come up with the company name? And is it a One Piece reference?
Yordis: it is. At the beginning I used to watch One Piece and I used to hate it. I was like, I don't get it, these ugly, cartoony things that was back in Cuba. But then I got hooked into it and it changed. It had a huge impact in my life in general. I learned a lot from that series. So yes, it's Straw Hat from One Piece.
Sundi: That is so funny. I was just talking about the art style of the anime today. I also wasn't very interested in it when I first got into it, but Now it's pretty iconic. I just watched all of the live action this weekend and Was thoroughly impressed. I Could not believe that a live action anime that is so goofy could be that interesting And yeah, when I first saw this about you, I was like straw hat.
Okay, that's an interesting coincidence I have one piece on the brain obviously, so that's where my brain went But then I went to your LinkedIn and I saw the logo and I was like wait
Yordis: reassembles way too close, huh?
Sundi: It's too, I mean, like, I think you're not in danger, you know, from any particular copyrights, for now.
Yordis: The good thing is I'm, I'm also Cuban, so I want to change it to be more like a farmer straw hat. And hopefully that's going to help me, but it definitely comes from there. That's, that's the root of, of it.
Sundi: Yeah. I love that. Can you tell us a little bit about Straw Hat, the, the company, not the pirate?
Yordis: Yeah. So I did a lot of consulting work and when I started with Elixir, so back then I was doing a lot of applications for customers here in Miami. So I. Did, from IM systems to, package management, I like sending packages to South America and whatnot, yeah. So like a lot of consulting work and open source with it. and that's, that's a good one. I need to bring my one. Sorry. 
Sundi: for those who can't see, Owen is rocking his Straw Hat right now. I kind of want one now. 
Owen: Oh, yes. It's a little hot out there, so you got to keep a straw hat around.
Sundi: Awesome. I think you all are in hot locations other than me, Yordis, you said you're in Miami? 
Yordis: Miami. Yep. 
Sundi: And Steven, you're in LA right now, 
yeah? 
Stephen: Yep. Granada Hills, north of LA, yep.
Sundi: Yeah, and even though Owen's t shirt says Brooklyn, I'm gonna assume you're in Dallas cause I see your sound panels right now.
Owen: That's right. Yeah. It, it's actually not that hot right now, but yeah, it was over the summer and that straw hat was super handy,
Sundi: Oh, you actually wore it?
Owen: a couple of times. Yeah. Wait. All right. I see your shade. We're going to move on. All right.
Sundi: No shade! No shade!
Owen: I will never wear that straw hat in public again. Let's talk. Let's talk about HTTP. so yeah, I think just to cover like for any kind of new Elixir developers we have here or any, especially new programmers, completely, what we're talking about is, you're writing an application, so maybe it's a front end or a backend application and you need to call out to another service somewhere.
It could be like an email service or let's say maybe a social network. They don't really allow that so much anymore, but you want to like, make a request From another service and get a response back. This is a big, long topic, and without getting all the way into the weeds, you know, there's a bunch of different ways of, making the request, and then on the server side, especially in Elixir, there's a lot of ways of building, responses and handling those requests.
So, that's the context of what we're talking about when we say HTTP requests and clients
Sundi: Does anyone know what it stands for? Just like off the top of their head.
Stephen: I do. It's, I think it's Hypertext Transfer Protocol.
Owen: Yes. We did it. 
Stephen: I pass the test. 
Sundi: Okay. I feel a little shame right now, because I'm pretty sure Dan walked us through, dan walked us through this like six months ago.
Owen: Ha, ha, ha. 
Yordis: Most of the time I say hypermedia instead of hypertext. I always confuse that one.
Owen: ah, right. And this comes up every once in a while. Like my favorite HTTP resource is http. cat. That's anytime I need to know which status code. I'm supposed to use, I go to this and this will show me the most, enjoyable illustrations of what went wrong or what was, successful.
So we'll make sure that's in our show notes for today's episode.
Sundi: For today's episode? It's been in every season since you joined us.
Yordis: I didn't know about that one. 
Owen: Uh, yeah, 
you know what? It's like, It's like, Pokemon and Sunday. Like I get to bring up HTTP cat every, every episode. 
Sundi: Yeah, basically. Yordis, is this your first time 
seeing that resource? 
Yordis: That's a good one. Yeah, Yeah, yeah, 
that's a good one. 
Owen: So, all right, so table stakes have been set for HTTP. Yordis, you are now maintainer of a, very popular HTTP, package for Elixir. Can you tell us a little bit about Tesla?
Yordis: Yeah, so Tesla is a HTTP package, as you said, it started from Timon and he's primarily the one who wrote it, most of the code, honestly. So the basic idea of Tesla is that it's not an HTTP client per se, but it's more like a library that allows you to have a middleware pipelining in front of the HTTP request.
So that way you could actually have a, rich ecosystem of. HTTP middlewares that transforms the request and the response. And then eventually we'd ended up in a specific client. 
Owen: Okay. And then how did, how did you become maintainer of Tesla? What's the story there? 
Yordis: Yeah. So Timon, send a tweet in Twitter that he wanted to take a time off and he needed some, some help with Tesla. And for me, I didn't know anything about maintaining Tesla at that point, but long enough in Elixir where. Uh, I feel confident at the very least be able to help people based on my experience from UberAlf as well and Guardian. So I just offer him to say, Hey, I. I can help you at the very least be able to close issues, maintain, you know, the CICD pipeline and guide people when it comes to, contributing to the package and whatnot. And slowly, little by little, just picking it up the pace and, you know, closing issues and implementing or refactoring new code. 
Owen: Right on. Have you had like any kind of minor or major releases since you've been working on Tesla?
Yordis: No major, we're, uh, there are a few things that definitely will require some major. Breaking changes for the most part, uh, related to gone dependencies, for example, so we're trying to avoid the major releases there. So middlewares introduce few things that is. Probably much better to break change and move on to with a clean slate moving forward, but not as far Intentionally been trying to avoid breaking changes as much as I can.
Owen: Right on. And Stephen, I know you've, worked previously in Rails, Javascript, you're writing a lot of Elixir now. I'm curious what your experience has been working with, different HTTP clients, or if you've written servers as well.
Stephen: Yeah, no servers particularly. I've kind of been more of a generalist in most of my career. I've been around the block a few times, had, had some exposure to, you know, jQueries, Ajax functions, , I tend to, as a generalist, I try to pick, like, whatever the, the kind of built in or standard library option is, so, whether it's, like, NetHTTP and Ruby, There was some fun with HTTP party or HTT party. I'm not sure, uh, speaking of hTTP puns, that was a fun, library in Ruby. And then later on at react, just using in the browser, like fetch, Axios, if you prefer, the promise based approach. But that's pretty much it for, you know, my, my breadth of experience. I wouldn't say I'm too deep on any of those things or look too much into the implementation details.
Sundi: I remember liking Axios, but I cannot remember why that feels like a dream, a part of my life that I don't remember before Elixir.
Stephen: Yeah, when I was doing some prep for this interview, I was like, Oh, I've got to go back and look at some of my older, GitHub projects and stuff. What have I actually used? You it's kind of a faded memory at this point. 
Owen: Yeah, I think I used Axios briefly when I was kind of getting up, up to speed on JavaScript and especially in the react days, eight years ago. Yeah, I think I've been spoiled whenever I've written JavaScript that there's so many new browser APIs. I was able to do most of everything I need to do with the fetch API. And I think Axios was like, it had some extra features, but I think by the time I was getting into it, Most of what I needed to do was just kind of baked into the browser.
Sundi: Yeah. And that's, and that's like a fair, fair kind of place to start is HTTP should be a fairly straightforward kind of situation. You're getting data, you're pushing data. And I remember having been in this industry for a little bit, and then I went to a part time boot camp where I had to build out my own requests, and I was suddenly, like, bamboozled by how to build out, with the headers and everything.
And I was like, why is this way more complicated than I thought? So can maybe we walk through the basic structure of what these requests look like, and why are we all making libraries about them? Like, still, right? Like, what is, what is it doing for us? Yordis, can we start with you?
Yordis: yeah, I think It depends on what level I think Hopefully most programming languages should give you a basic implementation of the HTTP client where it deals with the you know TCP connections and whatnot and all this, you know complexity but I think that's a level one, level two, for the most part is what Tesla at the end of the day is offering to one way and another one.
And is there a set of middlewares and filters and pipeline and pipelining that we want to create and reuse because we, we, to some extent are doing exactly the same thing that would allows you to declare a little bit easier, actually the life cycle of a request, like how you add the extra headers, the authorization, how to avoid.
Repeating the, the base URL in front of it. So that's the second layer that for the most part, even having fetch in the browser or HTTP CEO, which are, you know, native clients, you will probably end that up wanting, because otherwise it becomes too verbose and too much work to put together good practices and something that feels nicer to use when it comes to the application development.
that is where, like I share with you this, uh, the straw hat fetcher. And basically it's literally just taking Fetcher as the the end of the day and just adding that middleware so you could start sharing more middlewares between people for Open telemetry adding default headers the base urls and stuff like that 
Sundi: Yeah, and we'll include this GitHub link in the show notes, since this is a public repo. yeah, this is, like, a very basic, just, like, a nice primer to understand. You're looking through at the headers, the base URL, like everything you just said. And I remember, I think the first dataset I ever tried to fetch, on my own, like, not in, in the work, setting, was, and here it is, Owen, was a Pokemon database.
Hehehehehehehehe You know, bootcamps, they tell you, okay, get a data set, do something with it, and that's a really easy one. You fetch data from, or you fetch Pokemon, and they all have attributes, and sometimes they relate to each other in various ways when, like, a various Pokemon evolves from another one.
Not that you know this, the, the building of a Pokemon environment, Owen. But they evolve. And the, I don't know, I think I, I just really didn't know the basics of authorization and all of that back then. Stephen, do you know the history a little bit of why, why do we authorize the way that we do?
Stephen: Oh, you asked me a tough one. Well, I was going to take on the original one, which is yeah, you're right. HTTP is kind of abstracted away now. You don't really have to think about it too much, because there's built in libraries. There's a lot of different options out there. But yeah, I tend to think about it as , just an abstraction layer, where you can put all of your types of configurations.
 When you get into, let's say, you know, in a web application context, you're trying to fetch data from a server and kind of store it locally in the browser so that it's a little bit easier, and maybe , if it's a SPA, like a single page application, it can be more performant that way. And so, a lot of these libraries are meant to kind of handle...
How do you, parse out that data, how do you, , store it in, into whatever your client is so that it's convenient to use. So that you can treat it like it's a database locally that's available, , that kind of mirrors or fetches data from your server and then. locally for a client. Since you asked about authentication, I don't know, I mean, yeah, again, it's like, what do you actually need to do?
There's a lot of different approaches. There's token based authentication. I know, like, JST is a newer technology, for browsers, , which kind of works as, as you set up a, a token that kind of, It permanently authenticates you to an application, that way you don't have to keep logging in every time you visit a website.
You can close your browser, et cetera. So, uh, but please don't ask me any follow ups on that one.
Sundi: All right, we'll do, 
Owen: Yeah, I think in, in terms of like making requests, HTTP is kind of like what the protocol or the interface, there are some other protocols we can use. So we have GraphQL, RPC. I'm sure there are others, but in the web world, like those are kind of the three most to my mind. 
Sundi: yeah, in Elixir world, like before, I feel like a lot of folks now use Wreck for various things, Tesla, I remember once the first time I used Tesla, it felt like a Tesla. Not that I've ever driven a Tesla, but I don't know, like the first time I saw it work in real life before my eyes, I was like, why was that nice? That was nice.
Yordis: Yeah, I think one reason is that it came from rails though from the ruby ecosystem. The inspiration came from ruby. So there was already a learning in terms of what experience you're chasing after if you want to have that type of reaction from the end users. So I think that that's a really, you know benefit for many many packages I think in the elixir ecosystem that we all came from an environment where we value user experience Ruby and Ruby on Rails and how it feels to use it and The consequences is that we ended up sometime with, really a lot of learning from it.
Ecto is one of the other ones that, you know, we just avoid all the mistakes and bring everything that was good about, about the record. 
Owen: I gotta give you some brief praise, hope it's not to make it too uncomfortable, but I really appreciate the kind of the length of the readme, the structure, and then also the documentation for all of these modules that I'm scanning through. Everyone who's been working on Tesla, I think it's clear that not only the way features and functions and modules are named, but also. The way that there's documentation with examples written for a lot of this, that makes it super helpful to kind of get up to speed when you're using it for the first time.
Yordis: Yeah. I think, one thing I noticed, uh. depending on how many how to guidelines you have in a package in general, or some of these open source packages, it defines how mature it is. I noticed that the more how to showing people, Hey, probably you're trying to do this. It means that they already went through enough time and through enough pain that actually documented.
 That's something that I wish . Most people keep in mind, like document all the how to's and trying to do X and Y and put it in a written form. Trust me at some point, you're going to avoid having to be in a slack or in forum. How do I do X? Like, no, no, no, just keep collecting them. Doesn't have to be perfect. One thing that I didn't even know until months later is that. There is a wiki that Timon started, and that was the original way that he started documenting how to leverage it. I need to move it to the actual repository so people are more aware of it.
But that was a really smart idea, you know, really low friction to document things. It doesn't have to be top notch. It's not part of the, repo itself, but it's really, simple to get started and then start moving into, the package itself. And, and as, as an official documentation.
Owen: Yeah. And hex docs helps a lot with just having, seeing a standard, user interface for reading all of our hex packages with very few exceptions. It's really helpful for that. Now, I'm curious when we talk about actually making requests, what are some pain points that we've all had using different HTTP clients over the years?
I've done a little bit of jQuery back in the day, used Axios briefly, used Fetch, found Fetch to be good enough, at least for me. Stephen, like when you've been like calling out to APIs and making requests, what are some pain points you've had?
Stephen: Yeah, I mean, I think, working from both sides of the equation, right, front end and back end, , API design can be really difficult and challenging, because you have a lot of sort of needs and trade offs to think about. from the JavaScript side, error handling and all the different things that can go wrong, in the life cycle of a request, whether it be networking issues, authentication issues.
It could be something on the back end of the server is broken or it can't understand the request that you're making. And then being able to present that to a user in an understandable way can be very challenging. We kind of assume that the network's always available and that we're always going to be able to fetch the data that we need.
So that's one of the kind of the larger programming issues. And then as you're getting into kind of interpreting and understanding and collecting the data, you know, sometimes you're needing to make multiple requests to get, nested data. So you may request a list of users, and then you get a list of their posts, and then you get a list of the comments on the post, to use a common example.
 But each of those links in the chain could break down or could have some kind of issue, and then, , in JavaScript, you know, if you're doing the callbacks, you might end up with a deeply nested, structure that's just really difficult as a developer to kind of wrap your head around.
I think that's one of the bigger things that jumped out to me, with just kind of pain points on JavaScript. There's more on the Rails side, if you want to talk about back end, you know, performance is a big concern. Like I said, kind of designing the API in a way that... That isn't going to destroy your database, but also allows the clients to efficiently get the data that they need, can be pretty tough, but I think that's one of the reasons like GraphQL came about was, it, in some ways it decouples the client from the server so it allows the client to tailor and customize their own requests and makes that a little bit more flexible, which, you know, is nice as a client developer and then as a back end developer, you're not, you're not as concerned about it, so I think that helps. 
Sundi: Yeah, I figured that their, the pain points list was probably pretty long, because I swear, we keep making these libraries. I think even in Elixir alone, what did we have it before? Was it HTTP, I can't even say
Owen: It's Hackney. 
Sundi: Poison? Hackney?
Owen: Oh, wait. yeah, Both. Maybe. Yeah.
Yordis: yeah, you're ahead. Yeah. 
Sundi: take a, let's take a trip back.
Owen: So yeah. When I think about responding to requests, like if I'm writing a server that has an API that needs to respond to, you know, especially an elixir, I can respond to thousands of millions of requests generally fairly easily, but I can also shoot myself in the foot if I don't use some tools.
so a couple of things that come to mind in terms of like. Delivering responses quickly, you know, caching. So, like, you mentioned, , not hitting the database too hard. One way to do that is to keep, common requests in memory. So that, you can, respond a little bit more quickly and not have to reach all the way out to the database.
Especially if it's on, a separate machine on the network. It can help with that. Also, I was introduced to the concept of, I think, load shedding. Some time ago, and I think just in a nutshell, that's like setting timeouts so that a request can't remain open for, for longer than would be appropriate.
So maybe it's a second, maybe it's five seconds, 10 seconds or whatever. You can set those both on the server and then as a client, you can also set a timeout on your request so that. , if you don't want to wait, , a full, 10 seconds or whatever, you can time out after a second and then show some kind of error to the user.
But I'm kind of curious. So, so there's like ways to mitigate the pain points from the server side. Do you have anything kind of like any other kind of solutions you would think of, for improving response times?
Yordis: in the bottom layer is just the connection pool and I think that's one of the primary differences between the actual clients is how you're going to handle that connection and that's where you need to just meet your SLA. Sometimes it's not worth it just to chase too fancy, you know, implementation of connection pools when it's good enough to just create one, drop it and.
Have more like an a stateless way to deal with it. That's at the very least what I found the key factor when it comes to differences between HTTP clients and which one to use. 
Stephen: I was going to mention, there's like this pattern of a circuit breaker, which just allows you, if you have a situation where your server is encountering a lot of errors, like rapidly, um, It can, it can respond to that by kind of turning something off and then presenting some other type of data set, whether it's a static data set.
But, let's say your database is unavailable for a little bit of time, you're going to start seeing a lot of requests fail. You can have a failover for that data source or something like that. , that's just another, common pattern for, for dealing with that. 
Sundi: Another common thing I, I just kind of have at the top of my brain, because I did in the past, is how are how are libraries? Like, Yordis for you, how, how, what does 
Yordis: I have a hot take on that one. Don't if. It depends if you're building a client for an API and you want to offer us a package as a library, I think the best you could do is just avoid mocks or something like that and trying to do as much as you can integration tests, because at the end of the day, The mocking is as valuable as the installability of it compared to the actual production environment.
So the closer you are, the better. And since you're developing a library, that's knowing, hopefully not an everyday situation. Now, when it comes to the application level code, I think Joseph talked about this multiple times. I do not think that people should be mocking at the level and I used HTTP to do that, but, , nowadays I, they're just swap using a different function pointers, right?
Just a closure or define your behavior with an API that is closer to, the domain that closer to the HTTP. So instead of speaking about, I'm going to mock the get request to the user. In X client, you define a behavior that you would define a function like get use or something like that. And the inputs and outputs have nothing to do with hTTP per se. 
Sundi: Yeah, I think what, what I did or what I talked about in the talk where I talked about mocking requests and such was, and you can correct me if I'm wrong or not wrong, but like, if you see anything in this, lineup, please let me know. what I had recommended in that talk was not to specifically mock the request, but if you were dealing with a piece of code that relied on the request coming back a certain way, I would use the mocks MOX library to like define that behavior of like, I called in air quotes, this function, it returned in air quotes, this result.
And now we're moving forward with it. And that's what I did. But, I guess, is there any kind of, like, global testing, recommendation that you have in the Tesla, documentation?
Yordis: Tesla does have built in mocking, I would say that there are a bunch of things that actually help you to test , in the testing environment, there are some conversations about removing it and there is an open issue about it. Then long time ago and commented out, Hey, I found the useful, uh, which is called the, the, the, the, the more just called Tesla dot mock.
So that, that is going to help you to actually do this low level, mocking that you're talking about. So you could leverage that. And I used to leverage that until , I learned that, Hey, probably at the, in the application specific code, avoid that and probably do it more closer to a library that encapsulates a given service API. Yeah. But check it out. Tesla dot mock that's, that's a good starting point for mocking. 
Owen: we'll drop a link to the testing section of the docs for Tesla in our show notes as well. And that shows like a short example of using a mock, a Tesla mock and, and some other testing ideas. I think that'll be helpful. I'm kind of curious, speaking of Tesla, what are some lessons you've learned either about HTTP or just maintaining open source, , if I understand the repo correctly, I think it goes all the way back to 2016. Is that right? 
Yordis: Yeah, it is. It's maintaining open source. I also have to maintain the, we're often the guardian. So it's funny sometimes because people either are Vim users. Typing KK dot WW and creating issues. I'm like, okay, or other people saying bad words and creating issues.
Like, oh, sorry. So that, that part is actually always fun to me. I don't know. but, in terms of HTTP itself. Having to deal, the interesting thing with Tesla is I have to deal with many, many HTTP clients, right? So it's not just about Finch, I think is how you pronounce it, which is what Rack uses, but it's HTTPC, it's GAN, and that is challenging to say the least. And I have been forced to actually go into and learn more about HTTPC, GAN, specific things, finch, how simple it is to actually use it compared to the rest. And, and the second thing is trying to align with what other ecosystems are also doing. For example, how fetch in the browser behave and then how the, the goal library also the HTTP library from Golan behave and whatnot.
Because the, the closer we are to what is popular out there, the easier it will be for people just to, , jump into the ecosystem and, and being a predictive environment, to some extent. So, yeah, sometimes it's a lot of research. Let me see what they do to, you know, come up with a solution in our side.
Sundi: Stephen, what has your experience been working with some of these more HTTP client packages with Elixir since you've, you've been doing some more recently, yeah?
Stephen: Yeah, and we've actually used Tesla, , internally at SmartLogic on a, application where we were, pulling data from like a third party kind of CMS, , storing it locally, um, on the server to make that, data more readily available for users and caching it locally. , and yeah, since testing was kind of a hot button topic, that's always a big challenge, right?
Because you want your test. to run quickly. You want them not to fail because of external sources or, you know, networking issues. I've always found that to be pretty challenging. There are some libraries that take the approach of like, you can record the request and response and then use that as your mock.
 Which is nice. It's kind of like the VCR. There's . different libraries like that, that's cool because it kind of automates the process of setting up a mock of your data and it, and it makes it really close to what the actual real world, , data will be, , but then that can also get stale and you have to maintain that, separately.
So, I haven't seen any just great, easy, , fits all solutions for that, challenge. But, yeah, was interested to hear Yordis's opinion there. Um, so I don't know, that's, that's kind of some of my thoughts there. 
Owen: So we don't have one solution to rule them all when it comes to testing HTTP requests.
Sorry, folks, not yet. 
Stephen: Sadly, no. Still searching. 
Owen: Someday, right by the end of the season, maybe. yeah, so looking at kind of like some of the APIs we tend to hit. Of course, I've been on projects where Uh, CMS APIs are a big one.
I'm thinking of WordPress, social media, uh, APIs that we've been reaching out to as we're making Uh, Yordis, what are some, some APIs you can, 
Yordis: Yeah, it's funny. I, I created a Bittrex one, which is, for crypto trading long, long time. I don't look at that code by the way. Yeah. So I, like for me, yeah, Bittrex, uh, Platt as well as Stripe, custom I. O., move when it comes to banking, the last three I was working for a bank. So I have to deal with a lot of move, wire, ACH and whatnot. So primarily they all have OpenAPI schema. So that make, made it a little bit easier to actually figure out what to do and how. 
Owen: but, uh, Steven, are, are there some other APIs that you've, you've been hitting either in recent client projects or in the past, just 
Stephen: Yeah, Stripe's definitely a pretty popular payment processor. , I did have a crypto app where I was, I think I was using QCoins, like, APIs to kind of pull in market data. I believe that was using Finch on that project. , And, oh, Google Maps, too. That's like a pretty popular thing for apps. You might pull in a map and show some location data for whatever your business might be or something of that nature. Those are some of the ones that come to mind. 
Owen: I just had a flashback. I don't know, Sundi, if you were on this project at the time, or if you just remember me, my nightmares from, from this era, when I was dealing with HR, I'm not going to name it, this HR API that was, I think soap based or something. It was an XML and such a nightmare to deal with. Do you know which one I'm talking about? 
Sundi: Yeah, and the naming of that one was confusing as well for other reasons, but, um, I actually kind of wanted to, to talk about, also, like, it sounds like a lot of these things are using Finch and I wanted to talk about that for a hot second because I think it's very interesting that we had a lot of things leading up to Finch.
There were other libraries people were using, Finch just kind of snuck in there and then everyone was like, huh, I like this. And then all of a sudden, tens of thousands of people felt like, were like, I like this and now everything is built on it. I was like, where, where did you come from? Yordis, do, you remember when Finch got onto the scene? 
Yordis: I, yeah, I mean, I do remember some point, you know, the discussion of that, should Elixir actually have a built in client or not? And they did a little bit of research. If I'm not mistaken, that's where it came from. Mint was the one who was created and then Finch just took Mint and said, Hey, let me give you an easier. way to actually deal with, uh, with the HTTP client and give you some, uh, solution to deal with the, the, the connection pool and whatnot. Like you, you can decide what to do. I think it was Finch and Mint. I don't, I can't, I cannot remember, but 
Sundi: I, I think it was Finch. 
Yordis: was Finch. Yeah. I don't remember. But, uh, so, so that's that basically is like mint at the lower layer.
Like it's a stateless. We don't do anything related to the connection, but like I said, at some point you do care about the connection pool and like how to deal with that. It's statefulness of that connection. And I think that's, that's a really. Good value from Finch. 
Sundi: Yeah, I remember the first time I was building, the first time we tried to use Finch. And I was, again, building out a request for what it felt like the first time in my life, but obviously it wasn't. I was like, why am I not getting this? And then as soon as I did get it, I was like, Oh wait, I actually really appreciate this because when things are hidden, when they're done for you and they're hidden in a way that you can't really understand what you're even asking for when you're giving to a system to, to get something back, the explicit way I had to build out my request in Finch was super helpful for just clarity's sake.
Um, and then, you know, I closed my eyes and opened them the next day and everyone was using it. I don't know. I feel like Steven, you probably used it a bunch too, right?
Stephen: I mean, speaking of which, I, I'm so new to Elixir that, you know, maybe less than two years. I, I literally picked it because it was one of the popular options when I was looking for a library. So, yeah, the word of mouth really helps. I think I probably found it on the forum or a Slack channel somewhere. 
Owen: Yordis, could you tell us the distinction between a Tesla, like what Tesla's doing and then what Finch is doing? , I also used Finch briefly on a project. Uh, and I think Tesla might've made it my life just a little bit easier. 
Yordis: Yeah. So Tesla, Tesla, think about three major components. One is a data structure representing the request. Like think about it, like plug connection, plug count, right? So Tesla has built in that data structure called Tesla. env where you could actually mutate the request that you're going to give it to an adapter.
Or the response coming out of an adapter. So the second thing is that that actor component, the doctor is any HTTP client basically is, is a middleware that sits at the end of the pipeline that takes that Tesla environment and convert into whatever HTTP client you want to use under the hood, Finch, rack, mint and whatnot.
And then the third component is the middleware. So basically is this, extraction like plug where you have different plug, , middlewares that just give you a set of APIs that allows you to modify that Tesla environment. So that's basically what Tesla is. And that's why I say Tesla is not technically the HTTP client per se.
It delegates that to, to any adapters that you would actually implement. It could be Finch in, in one of the cases on Mint, but it's more focused on how to create middleware pipelining that you can transform the request and a response so you could actually reuse pieces when it comes to the lifecycle of a request without having to implement an HTTP client per se.
Sundi: Yeah, it's always fun to see how they, they build off of each other kind of in the end. I think there was something else called Mojito that was built off of Mint and I appreciate the pun there.
Yordis: . Wait, which is that one? 
Sundi: Maybe I'm making it up, but I swear there was one.
Yordis: Yes, there is one. 
Owen: Uh, HTTP client. Yeah. I was not even aware of that one. , Oh, it's deprecated.
Sundi: Yeah, I'm pretty sure it was old and we aren't using it anymore, but I remember it being there and it was based off of mint and I just found the names funny.
Owen: Interesting. So we've talked about some specific libraries and some patterns. HTTP is a protocol and so it's something we can use across multiple languages. Are there some best practices that you think Elixir could learn? Going back to the theme of this season is we're comparing notes between different languages.
Elixir has a lot of strengths. There are strengths in other languages and lessons we might learn from each other. Are there some patterns that we've all seen from other languages that we kind of wish we could implement, \ in Elixir? Let's see, Yordis, looks like you got something ready to go.
Yordis: Yeah. I mean, the, one of the major things coming from Golan to two years of experiences, and even now Rust is that when it comes to parsing into a data structure, like an instruct in Elixir. That is much simpler in other languages. , like I said, like go with the tag that you tag a key and say, Hey, just if you say JSON, if you're trying to marshal a JSON, just read this particular key and stick it into a specific struct key.
That is really nice. The same in, in insert in Rust. Which I wish Elixir itself has something, some answer for it, because most of the time, what you're going to realize is that putting together an HTTP client is simple enough, but wanting to actually give a rich data structures out is a little more complex. We move away from HTTP, Poison. Which he used to have a quote unquote declared way to say, Hey, I want just these data structures to be the return value and it would figure out how to create them and whatnot. But JSON itself doesn't have that anymore. So you have to do two passes when it comes to marshaling the response. You have to first use JSON to say, give me from stream to actually.
 Maps, and then you have to convert the maps into the structs that you want in Elixir. And that is a lot of time consuming. And most of the open API generators are extremely complex just because of that piece. So I think the biggest learning is, is in that front, what is the easiest way to declare a parsing from these streams base, data types into a more rich struct types in, in the Elixir land. 
Owen: And Steven, have you seen something maybe, I don't know if it's a jQuery or Axios or like something in Rails, which I'm less familiar with. Uh, something that you're kind of like, Oh, that would be a dream feature if we could just get that into Tesla or one of our many HTTP clients.
Stephen: I, I think one thing that comes to mind is, With the adoption of like TypeScript, is that you can actually, do typing of your, , API responses. Kind of like what Yordis was saying is, , it makes kind of that parsing, aspect of trying to understand what you're getting. To the browser.
I mean, this is in a JavaScript context, or TypeScript context. That can be very helpful, and it can also be much more stabilizing, because, you know, JSON is very open ended. You don't really know exactly , what you're gonna get back, and so you can kind of highlight and figure out. Where the errors are coming from a little bit more easily with that type of typing context, which I would think Elixir can do that.
I haven't looked too much into that on the Elixir side yet, but seems like a problem that, we might be able to approach similarly. , other than that, I think, yeah, just sticking with kind of the API, the JSON formatting. one of my former, companies. We used, , the JSON API specification, which is a request and response, , format that's very opinionated.
 It's very, well structured, but, kind of similar to GraphQL, it makes your, your request. It kind of allows you to abstract out the idea of like, what data am I going to be getting back? , it gives you all that information in the payload itself, like the types that you're receiving back from the backend.
 So it can be another link in that chain of trying to understand and parse out and, , make use of the data that you're getting, so, , I think that can be helpful, or just having like a really well formatted and well understood, , spec around, , the format of your data can be good.
Yordis: Yeah, this reminds me, Joe, because he used to say that between two services, there always should be a third service actually validating the contract between for the communication and what he meant was to me, I think what he meant was something like GRPC, something like GraphQL, maybe not the same implementation, but without that is, is a hassle in, in both sizes.
Oh, I think I, for me, like I say, I just want the the most clear a way for me to, achieve that validation between those two services. 
Sundi: Cool. We're getting a little close to time and I just wanted to make sure that we hit this one thing that we talked about a little bit earlier. . Yordis, you mentioned you have thoughts on collaborating on open source projects, and I just wanted to make sure we gave you the space to chat about that a little bit.
Yordis: Yeah. There is a new working group in, in Erlang ecosystem foundation called libraries and framework and primarily came out of, Zach and I just discussing, Hey, we, we wish we actually have an, in a space where we collaborate a little bit more than, you know, trying to put our efforts independently from each other without taking advantage of what each person could bring to the table. So I wish we have any space in the ecosystem where we have people collaborating around popular packages and figured out what is an actual breaking point for them, how far we could take them without having to start from scratch and creating a new package.
And yeah, so. Hopefully we bring it to the awareness of, there are a few discussions opening libraries and framework. One of them is related to the open API when it comes to, you know, related to the topic of HTTP. So it just, uh, you know, as, as a culture, it's just, hopefully we can actually encourage from, from the leadership to say, Hey, go ahead.
Don't, don't fear. Bring discourse when it comes to actually disagreeing with things and whatnot, because I, for me, I value more. That discussion and trying to find the breaking point and start over and, And assume that because you're starting over is going to be much better. Most of the time I found you're going to end up in the exact same place.
It's just different. you know Is this the exact same situation is just a tiny differences between each other and after wasting No wasting but after leveraging way too much energy into it too many resources and time consuming. 
Sundi: So, particularly for Tesla, but maybe just in general, how would you recommend somebody go about doing that? Like, just to engage on the GitHub or something like that? 
Yordis: Yeah, it's twofold I think , definitely from from the cultural perspective, you know keep trying to encourage collaboration over competition per se. But that also requires a library author , to expose themselves to, to social chaos, right? Because it's tricky sometimes. So it will record that as well.
And that's in the discussion part of it and disagreement we're always going to have. But honestly, we, if we trying to put our egos aside and say, Hey, what really would be the best outcome. Per se here, I think it would end up being a really healthy Result, especially the more diverse those discussions are. The other thing is library authors And i'm putting the ownership on myself We have to do a lot of work to make sure that we make the trivious way for somebody to contribute to a package And i'm trying to do that little by little that means a cicd pipeline have to take care of that means that contribution guidelines have to be repeatable for absolutely everybody.
That means that we as an ecosystem should trying to, collaborate and find some workflows that work. And, and I think that's, that's part of the intent behind the libraries and framework working group is having that discussion and lower the barrier for somebody to say, Hey.
I don't fear too much to contribute to this. So just let me give it a try and encourage that. And even from youngers that may feel like, Oh, this too complex. It's like, no, no, no. Open an issue, give it a try. Sometime I don't even know, but I'm maybe able to help you. And, and, and that, that is what, what count.
Owen: Yeah, I think to echo what you're saying, , so I'm a relatively new open source maintainer. I have a WebAuthn components package for like basically for passkeys in LiveView apps. And I think a couple of like practical things I've done to help myself. So a, I learned that like I wanted to have discussions, but I learned that I would not be notified when people would open a discussion. Which was unfortunate because I'm looking at discussions that were open a year ago and I did not respond because I didn't know or check on a regular basis. So that's on me. But also like creating templates, issue templates, PR templates, if PRs are open, that kind of thing. So that it's clear to the person who wants to contribute like what I expect and like what would help them help me.
So that there's a mutual benefit thing happening here. So. That I think has been super helpful. And, on, on all fronts, right. Everyone be civil. And even when you have a strong opinion, you know, present it with kindness so that, the maintainers aren't getting burnt out. Cause I've, I've heard those conversations also over the past couple of years, you know, there are maintainers who have backed off a bit from the social aspect, even, even if they really love their projects and it's kind of sad to hear that, but I think we all want to.
live in a healthy kind of open source environment. And, I think those are some, some steps we can all take as maintainers and as collaborators as well, to kind of keep things healthy space. 
Yordis: And I would double down on that one because I, sadly, some of those are friend of mine and the reason I ended up actually being core contributor is because I say, you know what, don't worry, I'm going to take the heat out of you. I know you're not having fun anymore. And, and yes. You know, respecting the, free time that most of them put, you know, like without money, resources or anything that, that's extremely important. Especially as we get older, I realized I'm no longer young. I want to do this all the time. So it becomes trickier if you want to have a life. 
Owen: 100%.
Awesome. Well, I think we are out of time. I want to make sure everyone's free to go back to work or not work, whatever you got to do. We're going to wrap it up here. Any final plugs or requests for the audience? Steven, we'll start with you.
Stephen: Uh, sure, yeah. On social media, you can find me at stepchud. That's the first four letters of my first and last name. Although I'm not much of a poster, I'm kind of more of a reply guy, . Um, and then my personal side project is harmonicdevelopment.Us or us. And, um, it's an app for the study in, in development of consciousness.
So if that's an interesting topic, Check it out, give me some feedback. I'm always happy to hear from people who may have looked at what I've done. 
Thanks. And thanks for the invite to enjoy the chat. 
Owen: Oh, anytime. And go ahead. You are to study. Do you have any plugs or requests from the audience? 
Yordis: Yeah, no, for me, like, if you want to connect with me, you can find me on Twitter, alchemist _ UBI, which You go, you can find me there. For me, the most important thing is just to bring to awareness the libraries and framework working group, like I say, having, people contributing either by sharing their frustration or whatever wish they have, like we, we need that type of feedback.
We need to be aware of it because, uh, without it, we don't, we don't know, right? So it's extremely important that we encourage strong collaboration and. Participation from the communities to make sure that we create what you want. Otherwise, don't be mad at us if we create something that isn't what you expected. 
Owen: Right. We will have a link to this. So libs and frameworks. I I've got too many tabs open now. I've subscribed to a couple of things, so I'll be in the comments. I'm sure, sooner or later. So thank you both for joining us. Yordis for maintaining Tesla. I think we're all benefiting from the work you and the Tesla collaborators have done over the years.
Steven, thank you for being a great team member here. And for jumping in to help us out with this conversation. And thank you, Sonny, for being a great co host and we'll be back next week.
Track 2: Elixir Wizards is a production of SmartLogic. You can find us online at smartlogic. io, and we're at SmartLogic on Twitter. Don't forget to like, subscribe, and leave a review. This episode was produced and edited by Paloma Pechenik for SmartLogic. We'll see you next week as we branch out from Elixir.