 Hey, developers, you know that debate that we always have as developers where it's not the tabs versus spaces thing, but as the whole, should you go straight to an endpoint like the rest endpoint, the raw endpoint, or should you use some SDK that's provided to us? Tons of examples for this all around. Well, today in this episode, that's what Julie and I are going to talk about. We're going to talk about the pros and the cons about using REST versus using SDKs. You can tell we're new to this, right? Yeah, we are new to this. We got the button clicking down though. I'm doing good. How are you doing? I'm doing just fine. I'm doing just fine today. So this is our fourth episode. I guess our first real topic or meet in potatoes. There we go. Potatoes, good table stakes right here. This one, this topic, this one we want to talk about today in this episode, episode four of the Cloud Dev Clarity show is around the discussion around should you use a REST and go straight to a REST endpoint or should you use an SDK that is some sort of a wrapper to that endpoint? So I'm going to go with ladies first. I already know what your opinion on this is, so I'm going to give some background. No, I'm going to give background. I'm going to give background on my opinion and give you my opinion. I think it's probably obvious to most people that I might say SDK because I do co-maintain an SDK that does this very thing. But I want to go to the backwards a little bit and say that I didn't always feel that way. When I, we talked about, you know, in the Getting to Know Me episode that I helped, I co-wrote a library, sort of a little mini library for loading code into a content editor or a script editor web part called the Widget Wrangler. Bob German and I did that together. And one of the things, you know, about doing that is we started writing all of our solutions for clients and whomever using JavaScript and sort of had abandoned server-side code. So no more add-in, you know, no add-in model, well, add-in client-side code, but you know what I'm getting at. We weren't doing any of that kind of work anymore. And so when I first started writing JavaScript and using the 2013 REST endpoints, I absolutely was all about writing my own. So I had my own helper file that had, you know, all the, you know, the post, the get, you know, all of those things with different strings for the, you know, the URLs that I used pretty regularly and managed, you know, what site collection you're in and how to change the site collection and all that kind of stuff I did all myself. And it was quite a while before I actually switched and tried PMPJS and then eventually adopted it. So I think at this point, I am in general in the SDK camp but I would, yeah, pro camp, but I'm gonna caveat it to say that I'm really picky about it. Like I wanna know exactly what's inside of that SDK, how it works in general before I'm just gonna blindly use it. So yes, mostly I think is my camp. That's, I mean, that's fair. And just for our viewers, when you say PMPJS, that is a JavaScript library works both server side with node or client side. That's right, it's written in TypeScript. It's, yeah, and it handles, well, I'm just saying it's written in TypeScript. It's handles all of the SharePoint REST endpoints as well as a chunk of endpoints to the Microsoft Graph using sort of a, what we like to call the library internals sort of a internal reusable pattern for making those calls, handling retries, formatting headers, et cetera, et cetera, et cetera. Yeah, okay. So yeah, I mean, that's fair. Do you have like, actually, so you've kind of just put your flag on the ground. So let me put my flag on the ground and then we can kind of go, we can go back and we can go back. Yeah, yeah, yeah. I mean, I guess like you generally, I don't wanna say that it's an absolute, I don't wanna do an absolute and just say that I absolutely don't like this or I do like this. My default position on it though is that I do tend to gravitate towards going straight to a raw REST endpoint than I do on using an SDK. There's a bunch of reasons why I don't particularly, why I try and stay away from an SDK. There's times where I will go to it because I wouldn't, I don't wanna make an absolute statement because if you look at any of the projects that I do, you would see a pretty good mix between the two like, well, why do you do this instead of this? And why do you do this? I was wondering that. So that'll be interesting. I'll be interested to hear some of that. Keep going, sorry. I mean, I generally wanna go more with like the REST endpoint. So like taking your example just a second ago and using like PMPJS to talk to the SharePoint REST endpoint or talk to the Microsoft Graph endpoint which is also a REST endpoint. I never use anything like that. I've never been a big fan of the CSOM, the client side object models. I mean, we had legacy manage code thing that we had for talking to the SharePoint REST endpoint. I don't use the PMPJS library as well. And I think the majority of the reason why I don't like doing it is because I don't like to take dependencies unless I absolutely have to because there's baggage associated with dependencies. Yes, there's things that you get with those dependencies like for example, like with you guys you have a way to simplify the initialization of it or being able to reuse the same context multiple times on the same page or having to go through multiple real initializations. Whereas if I wanted to do that I would have to build up my own infrastructure to do that to share as a singleton across the page or across multiple pages. But I generally try and stay away from those dependencies and I have multiple reasons for that not just to avoid a dependency but I think one of the reasons that I really dislike about it is that I feel like I have to always the Majutna always, stay away from absolute statements but I find that more often than not that an SDK is an interpretation of someone else's rationalization of the same thing I'm trying to get to. And when it's a restful endpoint or a rest endpoint that I'm going straight to it there's no debate, that's how it works. Yes, there's a lot of like helper stuff that can be added for it. You guys have like a caching model and stuff in it. Obviously I'm not gonna have that but I just find that I would, I prefer to have less of a dependency or less of a dependency chain or minimize it as much as I can. Yeah, I mean I'll give you an example of where that maybe is a really good point. Like we have switched when we went from version two to version three to the library, we switched from using verbose in the header to, so the payload changed, you know what I mean? And so the parsing of the payload changed and I think there's, you get OData metadata, thank you. And I think there's an argument to be made that and full disclosure, it's super easy to change that now in the version three of the library but still the bigger point here is, you have to have thought about it and maybe if you're doing the calls in a more pure way and not using an SDK, you're gonna be more thoughtful about what you're doing. Like, oh, my payload is huge. Maybe I wanna think about how I've configured this, you know, header to make these calls or, you know, maybe I wanna make sure I do a select. If that is sort of obfuscated away from you, you may not think through what you're doing as well. So I'll give you that argument for sure but I think if you, from my perspective, I do know what I'm doing, I do know how the library works very intimately and so the fact that I can so quickly write great, big, huge pieces of code that do a lot of work with a short amount of code, you know what I mean? The code is still there, I'm not saying it's not but I'm sort of saying the code I have to write is significantly less, especially when I would say 95% of the work I do is like, okay, you know, create the library, create the columns, create this content types, pull this data from here, grab that data from here, merge that data from there, add that thing, take that thing, you know what I mean? So I'm doing so much work that the ability to have something sort of take some of that away from me is really, especially just the extra calls, right? If I do, if I request like the items from a list and I await that result, that result's already gonna be parsed for me into a JSON object, that's kind of a win, you know? It is, that's a good example of the differences, right? So when I go, when you want to use like the Fetch API, the native in all browser, sorry, native in all reputable browsers, I'm talking about you, but even, even Kredge has it. So that when you want to call a RESTful endpoint, you're going to get a response back, but then right when you get that response back and you want to go work with the data that was returned in the body, if it's JSON data, you have to call, you know, response.json, which is gonna be- And await that promise. And await that promise as well, right? Until you get that data back. So it's whenever I go to get data, because I don't use something like PMP or some of the library to get my data, it's always a double call. I'm making a call to the endpoint and wait for that promise to resolve. And then I'm waiting for the JSON call to resolve from that promise as well. It's something that, I mean, it's a pattern that I'm used to. Here's, so here- What about re-driver logic? But go ahead. Oh, I got to build all that myself. Well, I'm saying, so that's like- I'd have to do all of that myself, which- For every single call. Or you have to encapsulate it into some sort of class to handle it to blah, blah, blah. Yeah, I mean, and that's a classic, well, I mean, I guess when it comes to Microsoft SDKs, you're gonna get, it depends on, sorry, Microsoft endpoints, you can get throttled. And so- Yeah, you can get throttled, you can get 500 internal server errors on the SharePoint endpoints a lot. Like you need to be prepared for the fact that they're a little fragile sometimes and they're not gonna be, I mean, they're up most of the time. I'm not saying they're like completely terrible, but you know, you have issues and you need to be able to handle them. So this is, and this is gonna, this is me trying to like shoot down the SDK argument, okay? Okay. But one of the things that I see from, and this is not a personal attack, don't worry, don't feel bad. I'm not the attack. One of the things that I see from my students that skip going to the raw endpoint, and instead they go straight to just using some sort of an SDK or some sort of a wrapper on it. For example, they use PMPJS. They will run into a problem. Yes. And my first reaction to them, or my first question back to them, is go look at the network tab, client solution, so SharePoint framework developer, go look at the network tab and go look at the underlying calling. Here's my call that I'm using with PMPJS. Am I going, yeah, I don't know that. I know the REST call, show me the actual REST call and they show me the endpoint they're going to. Yeah, there's no site in there. I don't know, you're not setting the site. Well, how am I supposed to set the site? Well, it's got to be in the URL right there. So it's either one of two things. You're either not holding the SDK right or the SDK has a bug in it because it's not actually sending the site over to it or you don't think, yeah. Or the developers, you don't really understand exactly how this is supposed to work. And they didn't, and I find that the majority of the time that a lot of the times when they run into stuff, when things break, they're like, yeah. I don't know what to do now, I'm lost. I'm like, I just, what am I supposed to do now? My car GPS is dead, like you're gonna get a map out. I have no idea which way is north, like. Yeah, and again, I'm 100% with you because I answer issues like that in the PMP repo a lot. You know, didn't find the right piece of documentation, didn't understand how the library really worked. And I'm gonna go back to my original comment, which is to say, you know, if I'm gonna take on using an SDK, I'm hoping that I'm gonna have a pretty darn good idea of how it works under the covers before I take that dependency. I mean, I have this conversation with people and my more famous one was when moment was the thing that's been replaced, it's deprecated. But, you know, like people would use moment JS, the library, excuse me, the JavaScript library to like do one date manipulation. So they take a dependency on a whole library just to do like one date string manipulation. I'm like, you do realize you can just write that one line of code, right? They're like, that's not undoable. I mean, if you're gonna make an entire app that's based on date time manipulation and multiple time zones and all, yeah, it gets confusing fast. And having a library that sort of helps you make sure you do those things correct is quite honestly a godsend. But when you just take a dependency on something, you really have zero idea of what it's doing, how it's doing it or anything else, you're gonna end up in that position where you're having to learn. Now, I will say this and I say this all the time. That's what being a developer is all about, right? I mean, we were talking offline about, you know, the fact that I'm learning something new right now and it's so painful, but it's also joyful. Like I'm like, wow, I haven't had to learn a new, you know, language slash library or slash pattern for doing something in a really long time. Yes, it's frustrating. Yes, I make dumb mistakes where I have strings that I copy, pasted wrong or forgot to change or whatever and frustrate myself for hours. But I think there's a mentality issue that you're sort of addressing that's different from the actual issue, which is to say that if you're using an SDK and you don't understand how it works, knowing the path to reverse engineering and figuring out, okay, let me go look at the network tab and look at the calls because all this thing is doing for me is abstracting away those calls. Let me see, is the call being made the way I think it should be made? You know, is it, oh, okay, but the result is not what I expect. Okay, that could be with the library. Oh, I'm making the call, but it's not what I expect. You know what I mean? And like having that sort of mentality to troubleshoot into, you know, versus the, well, it doesn't work, I give up, you know, I mean, that's different. Yeah, that's totally fair. And I mean, if you're not, if you're a developer and you're not in the mindset of enjoying the process of learning and trying new things, kind of in the wrong business, I think. Yeah. I think, so one of the, I will say, so we talked a little bit about this in the intro or like teasing it up as like, when do I try to, when would I avoid going straight to an end point? Or if you look at my code, you look at my projects, even though I default to the rest end points, when do I go with an SDK? Yeah. Couple really good examples. I'm generally not a fan of the SDKs, I guess the ones that come from the Microsoft 365 group. So like for example, I don't like, I don't use the ones that come out of anything that we have from, for talking to SharePoint. It's nothing against PMPJS, it's just, I know the rest end point, like I can still get the same thing done and I don't, there's nothing that tells me that I, that convinces me why I should switch over and start using this because I, and I see the benefits that it would give me, but I'm like, I haven't gotten to the point where I'm just like, that's gonna help me on this project. Same thing with like Microsoft Graph, I don't care for it because I don't like the fluent based way of building out a call. I understand just, I think better with like the rest end point, but there are other ones that do make a lot of sense to me. Like for example, even though there is a restful endpoint for Azure application insights, I use the JavaScript SDK and the web SDK for that. Yeah. Why? Because there's some stuff that it does that I don't have to think about. So for example, it wraps up an entire session into what's called a correlation context. And so I can see that all of this stuff went without one user while he was on the page or she was on the page. Or I can see that when I use app insights in the context of an Azure function that the second the function spins up, I ask app insights, create a, create a correlation context. And I want everything that happens with this execution of this function to be wrapped up inside that correlation context so that when I go to debug something, I can see that everything about it, when my code, all I did when I wrote my code was, you know, trace this message or with these additional properties. But I don't have to worry about all the other stuff of things that it does for me. Like it has a concept of a letter that goes into an envelope. And I'm always writing the letter, but I want additional things shoved in the letter and some stuff written on outside the envelope with every bit of payload that I sent. I don't want to do that in my, I don't want to do that in each one of my methods and everywhere I'm calling those tracing and tracking things, I want the library to do that for me. When I talk to a couple of the different, some of the Azure SDKs, they're going through a huge rational, re-rationalization and rewrite of all the Azure SDKs right now. And I find like talking to things like storage blogs and cues and log analytics, they all leverage the Microsoft identity package. It makes it, there's things on like the authentication side where like, here's a good example, the Microsoft's identity package when you're working with it with Node, it has this hierarchy of three different chains that it's going to go through to try and figure out the credentials that you want to use to take it away from your app. Yeah, yeah, yeah, yeah. And so I can start and the first thing it does is it tries to see, is there an environment variable? Like, or specific environment variables like the name, the password, the client ID, key, something or other. Yeah, I can't think of the name of it, but yeah. So it tries to find it from that side. If it doesn't find it there, then it's like, okay, are you logged in to your Azure account on using the stuff that we have in VS Code or Visual Studio? So if it doesn't find the environment variable, then it goes to that and it tries to use that. And even if it is there, it goes, you can fall back to another one. So something like say in a string of password inside of some sort of a settings key. And then the next one is, now we're gonna rely on like a federated or a managed MSI. Identity, yep, yep. Service. Ha, ha, ha. Oh, I just, I just, I just got, I just got a month of work. But a managed identity. Yeah, it's gonna get, it's an MSI, but it's like a managed service identity, I think is what it's called. Yes, I think so too. Service principle. But there's that identity where I can say like, hey, it's running in my Azure function, even though I'm testing it locally on my laptop, I've got, I'm logged in with VS Code where I'm logged in with the Azure command line interface, use that as my credential. But hey, when you're running in the Azure function up in Azure, that function has been added, granted a specific role using RBAC on the storage account. And so it knows to grab the different credentials. So I don't have any credentials in my code because I'm using this one SDK. I could write a lot of stuff myself, somebody did, but. I do like those. So that's the, that was the other thing I was gonna kind of go back with is like, there are some of those identity libraries that when you're developing and you were talking about cloud services, they do make your life so much easier. I mean, that would be a ton of code to have to write. So, I don't know. It is, I mean, I know that we're gonna talk about it at least in one of these episodes, if not a thousand of them, is when we talk about MSAL and Microsoft authentication or Microsoft identity, I should say Microsoft identity. But for me like MSAL, like I can't stand the MSAL library, the Microsoft authentication library that Microsoft provides. Yes, ton of code in there that does a lot of stuff that supports all these different flows. But I'm like, if it's my project, I know how to go authenticate. I don't need to go through all that stuff. And some of the things that these different SDKs do, it's their own interpretation of how the authentication should work that I don't need, that I don't need to follow their interpretation because it works the same way across different platforms. So, real world example, the Microsoft identity supports OAuth 2, and specifically when you're doing an interactive login, you generally are gonna use the OAuth code OAuth flow to obtain an access token or to get an authorization code that you're gonna use to get an access token. MSAL lets you set up all the configuration and stuff like that to do that, to talk to Microsoft identity, to go through the authentication, to get the authorization code, and then to use that, to exchange that with the client ID in exchange for an access token, and the secret for an access token, a delegated access token for the user. I recently built something to log in to Discord, and Discord also uses OAuth 2. It also uses the OAuth code flow, but because I understood the OAuth code flow, implementing the code to do that piece of cake for me. It was not very hard. It was surprisingly very little code, but had I done all of my authentication stuff using MSAL, I would have been like, well, where's the method that I call and pass this and this and this in? Because all that's plumbing stuff that's in that black box of MSAL, I don't understand how that stuff works, but I do understand how the protocol works, and so when I did it over in Discord, I didn't have to figure out how to make this call over in Discord. It's the same thing. That's the trade-off though, that's the, I understand this pattern and I'm choosing this SDK because I do understand the pattern. I think that this SDK implements it well, and I think that it will provide me a quicker way to get from A to Z knowing that I know what code I'd have to write every single time. And I think that's the point. I mean, I'm not saying I've never taken a shortcut. I have, like, oh, I've gotta do this one thing and I don't really know how that works, but this is like, I could just do these three lines of code with this SDK and that piece would be done. That might be good. I'm not saying I've never done that, I have, but I'm saying that if you're talking about an SDK that you're gonna rely on on a regular basis to write your code, you should understand it or understand what it's replacing for you or what it's doing for you. And your example of authenticating and especially, I mean, I think this is different for, depending on what you do for a living, right? Like if you are someone who is only authenticating against Microsoft stuff, whatever that might be, MSAL can always get you there. So it abstracting it and you not understanding it maybe is okay until the day you need to do something different. And so, I think your experience is more that you work against a lot of different platforms that are not just Microsoft platform and thereby you understanding that really well means, you're like, well, I don't need that library to do something that's gonna take me just this little time to do, right? And I think there's a lot of people who use it because that's hard and they wanna get to writing the code and I don't really wanna understand the black box, but I think that's dangerous. That's my opinion. Well, but you bring up a good point. You actually, you bring up a really good point because in that case, I think you bring up a really good point. The reason why I say is because it like, I'm also coming at it from the perspective of an educator, of someone who's trying to explain stuff to people and to, and help them understand how stuff works. And so, yeah, I'm talking about different. I find that if you ask, the best way to learn something is to ask why. Hopefully five times, but when you're learning it, but ideally as deep as you can get it because the more that you can answer that why question, every time you turn around, the world's not flat. Why? Because it's a circle. Why is it a circle? All that kind of stuff. Well, I'm sorry. I was just gonna say. I hope I didn't get you to stay in our listers. I'm sure there's some, well, it's a sphere, I know. I was assuming that the flat thing was kind of a. Oh, okay, I got you. Two dimensions versus three. I'm with you. I'm with you. But there's that. But then, yeah, I agree with you that there are, that if you're only doing, if you're only working with Salesforce, you only care about their authentication stuff, which a lot too and blah, blah, blah, but they go to a different authority. Whereas our authority in the Microsoft world is Microsoft identity, which a lot of us refer to as Azure AD, but it's Microsoft identity. Right. So, yeah, that's fair. That's totally fair. So. Doesn't mean that it's always simple. I mean, if you, we're gonna have probably a separate conversation on authentication. Yeah. Margaritas. We'll schedule that one for late in the day. But, you know, there's a lot of different flows to your point. So, you know, whatever. I mean, we don't wanna go down that road, but the SDKs can maybe make those things easier for you, but you still have to understand which one you want and why you want it. And so back to the original point, you really should know what you're doing, why you're doing it before you just blindly start like copying code and pasting it in and hoping you're gonna get the right token. You know what I mean? Yeah. And you just, you have to, I hope that what we've been trying to put across in this episode is not, one is better than the other or one is worse than the other. It really, it's in the eye of the beholder. Right. I wanted to present the, I know I'm on one side, you're on the other side in terms of what, I guess what our general default positions are or how we first come at something. Right. But it's, you know, it's like sitting down in a restaurant. What are you gonna go for first? Some people go for the entree, some people go for the appetizer. Some of us are going for the drinks first. And then that's gonna help me make the next decision. And then you have the thing, like do I have the appetizer because it looks so good in skip dessert or do I have dinner entree and then have dessert because the desserts look so good. This is why you have to see the entire menu, right at the beginning. Yeah. But that's exactly the same, right? It's like this. You just have to, what's your default position? And at least have a, have an understanding of why you do it, why you're going at that thing, why you're going, why you're approaching it like that. I, I find people just sometimes will just start grabbing everything and throwing at it. I want to do this and mix and match everything. And it's like, you need to kind of at least have a pattern for why on how you approach stuff. It's not that your pattern is wrong or right or that it's better than somebody else's or worse. Just like the restaurant example I gave a second ago, we're all going to look at stuff differently. It's always kind of, it's one of those things. You sit in a restaurant and you go with a bunch of people. It's like, watch everybody else opens up their menu. How do they do it? Like what are they doing first? Are they going, are they just first page and let's look at all those appetizers or it's flip it over. Let me see where it's your cocktails are or can I have the wine list, right? Right, yeah, yeah, yeah. So. Well, it's exactly that. Well, that was a really good discussion. I think we, we sort of beat that. I hope it was. Well, hopefully, well, hopefully, right? Yeah. So people, what did you think of this episode? Did you like it? Please let us know, drop a comment below and submit a topic for discussion in those comments. And if you really liked this video, please give us a thumbs up and subscribe by clicking on that nice red subscribe button. I'm sorry. I'm sorry. And you'll get, what are you doing? I'm nervous. So, he's dangerous people. He's dangerous. I'm trying to fix it. I'm trying to fix it. Sorry. So if you liked this video, please give us a thumbs up, subscribe by smashing the subscribe button and then you'll get to know when we publish more Cloud Dev Clarity episodes for developers on the Microsoft 365 and Azure platforms. Thanks for joining us today.