July 26 | Live Q&A for End-to-End Workflow Demo

And as people are jumping over, I'll have us introduce ourselves here. But I can see we just successfully went live.

Hey everybody, thanks for jumping over here to the Q&A. We're gonna give people another minute or so to make sure the redirect worked well for everybody.

But thank you so much, Ryan, for the great demo.

Okay, well, I think we can get started and people will find us over here in the Q&A. But there were a few great questions in the YouTube chat already, but just wanted to remind people that you can ask questions anonymously as well. And so you can use this link that I'll show on the screen here, pos.it slash demo resources.

But for everybody who just joined us over here in the Q&A, hi everybody, hope you're having a great Wednesday and thank you for joining us again. I guess we could all introduce ourselves over here too. I'm Rachel, I lead our pro community here at Posit. Ryan, Katie, Ralph and I are gonna hang out here for another 15 minutes or so and answer some questions. But I'll have you all introduce yourselves as well. Katie, if you wanna go first.

Sure, thanks Rachel. Hi everybody, I'm Katie Masiello. I'm on the solutions engineering team at Posit.

And Ralph. Yeah, thanks. My name is Ralph Stupner. I'm also on the solutions engineering team at Posit.

Awesome, and Ryan, I know you introduced yourself before, but how about again? Yeah, absolutely. So I'm Ryan, I'm a data science advisor here at Posit and I'm the person whose voice you just heard for the past 20 minutes.

Well, actually this is the first end to end workflow demo where Ryan and I are in the same room as well. So it's funny sitting here side by side on the screens, but let's jump into some questions.

APIs vs. stored procedures

So I see over from YouTube, somebody had asked, we're thinking about using APIs and a lot of our data is in Microsoft SQL server. Would be very interested to hear what are advantages of using APIs over using stored procedures?

Yeah, I can probably start on that and then maybe Katie and Ralph, if you have any other additional comments, but really it's gonna differ based on how your team operates. So if you have a data in a SQL server and you can push certain operations to that SQL server so that it transforms your data, cleans it up, you pull in the data that you want, then that's a great solution for your team. I think APIs in the context we presented it today as kind of like a data portal, so to speak, you can do a lot of those same things. So it's really gonna depend on how your team operates. If Microsoft SQL works well for you, then that's awesome. We certainly wouldn't say, jump ship from that and switch over to an API, but just know that an API is a data access portal is a great solution as well.

Yeah, maybe one thing is just language familiarity. So the SQL, the sort of procedure you would have to write in SQL and maybe people are familiar with writing a dplyr pipeline, but not with writing the appropriate code in SQL. And that could help with the API, especially if you combine it then with the dbplyr package, which automatically translates your dplyr pipeline to SQL code so that it runs in the database and is still fast to return the data. So yeah, it can be interesting if people are more familiar with R than with writing SQL code.

POST requests and authentication

But one question that I did hear, or not hear, see over on Slido was would love to hear a bit more about post requests and how that interacts with local file storage. So best practices, well, you can read it there on the screen too.

That is a great question. So APIs, as I mentioned during my webinar, I avoided APIs for a very long time because they scared me. But I would say over the past year or two is when I really started to leverage them more for kind of simple tasks like we talked about today. It's like a data access. And so based on my readings, for data access, a lot of times we use these kind of post requests or get requests, but there's so many other different ways that you can ping an API. And depending on what you're receiving, you may want to adjust kind of what you want to say. So I know there's a bunch of other options out there depending on what your API is going to be doing. And so I would just say, it might just be worth doing a little bit of research to make sure that you're using the right type of request from an API, depending on how you're interacting with it. But again, my API knowledge is pretty limited. So I don't know if Katie or Ralph have anything else they want to add to that.

Can you share more about tokens? Are there possibilities to have something set up so folks outside of our organization can request tokens?

Yeah, and I think there was a similar-ish question in the chat as well about like authentication for your APIs. So in the context we presented today, taking an API, it doesn't have to be a FastAPI. It can be a plumber API, it can be a flask API. And once you publish it to Posit Connect, Connect essentially allows you to add an authentication layer to your API so that it's not just opened up to the world that anyone can use it. So in my demo today, I actually made my API essentially open to anybody. So if you open up a terminal command line, or you just call it from our Python code, you can essentially ping the same API. But I could very easily, as a publisher and owner of that piece of content, I could switch the authentication so that a user would essentially have to provide an API key to this API in order to leverage it. So in combination with Connect, you can add a layer of authentication to your APIs.

Now, in terms of like these API keys and sharing with people outside of your institution, that's probably gonna be a good question for your account manager in terms of licensing and how that's gonna work for Posit Team and Posit Connect.

Pins vs. FastAPI for Shiny

Could you discuss the pros and cons of Pins versus FastAPI for Shiny?

Yeah, that's a good question. And thankfully I'm joined by one of our Pins experts, Katie, but I can at least talk a little bit about it and then pass the mic over. But Pins, and if you actually go back to our last month's demo, I believe, we actually talked a little bit more about Pins and how you can use it. And we did it in the context of just grabbing a data set and pulling it into a Quarto document or a Shiny application, for example.

But Pins, for the most part, they're fairly static. So you have a data set, you clean it up using our Markdown or Quarto, and then you pin it, same way you would pin or save something to like Dropbox or Google Drive or something like that. And once it's there, you can share it, and that's a great use case. But a benefit for like FastAPI is that not only can it serve as like a data portal for you to get data, but you can also do things to that data. And so from our webinar today, you saw that I pinged the API, but at the same time, I added some query items. So I said to API, like, hey, I want the data, but only give me the data where the rows are equal to like A, B, and C. And then I get that data back, so only that data. So there are ways FastAPI can probably do a little bit more compute for you. You can place it into a function in Python and R and kind of wrap those functions into an API. A lot of the work you would do in your Shiny application, you can essentially push to an API. And that's always a lot of times best practice when I'm speaking with folks that have these Shiny applications, and they're big, they're clunky, they're slow. I say, you know, if you can take any compute, anything that doesn't need to be in that Shiny application and move it to something like an API or maybe a Quarto document scheduled to run or a pin, just kind of move that stuff outside of the Shiny app, that typically will set you up for success in the future.

that typically will set you up for success in the future.

Yeah, I think that's pretty solid, Ryan. The big difference that I think of is an API, whether it's FastAPI, Plumber, right? It's just a way of wrapping up a function. So you're doing something. And in the demo that you did today, right? Your function was accessing a data frame and filtering it. But it could be a function that creates a model or does a coin toss or whatever it is. And so it's doing a function and that's just wrapped up as an API. Whereas a pin is you pin an object, whether it's a data frame, an image, a list or whatever, it's an object that's put into a place where you can share or collaborate or reuse in different places. So it's sort of different use cases. We sort of saw a bit of an intersection today for the use of sharing data, but under the hood, just keep in mind that APIs, you're going to be a bundling up of a function under the hood.

Language-agnostic front-ends and API frameworks

I see John asked a question over on YouTube that said, am I right in thinking this approach will make it fairly straightforward to link up-to-date summary info with something like a React app? This really helps keep the front-end language agnostic.

Yeah, I would think so. That's exactly one of the nice use cases for APIs to have potentially multiple front-ends for one piece of logic. Mm-hmm. Yeah, when I was working on this content, I was speaking with some folks at Posit, like, you know, what's really the big thing that advantage APIs provides? And it's exactly what Ralph mentioned. You might have completely different pieces of content. So we talked about Shiny app in R, Jupyter Notebook in Python or React app. It could be something completely different, but APIs provide that kind of common communication layer so that it can speak to those functions that you developed in Python in R or whatever. So again, I always like to go back to that restaurant analogy. So your API is the waiter or waitress that allows the customers to speak to the chef. Customers might be from different parts of the world, speak different languages, but hopefully your waiter or waitress can speak those languages and communicate between the chef.

So your API is the waiter or waitress that allows the customers to speak to the chef. Customers might be from different parts of the world, speak different languages, but hopefully your waiter or waitress can speak those languages and communicate between the chef.

But while I'm checking, one question I did have for you all was, how would you choose which API framework to use?

So I'm an R developer, more so than I am a Python developer, but you'll notice today. If I had to very quickly on the fly create an API, I would certainly probably try to use Plumber because that is kind of a wrapper on the R programming language. I'm just a little bit more comfortable with that. But if you're a Python developer, you may be more comfortable with FastAPI. So I think the take-home here is that whatever you're most comfortable leveraging, you can find a framework for creating APIs. So Plumber for R, FastAPI, Flask in the Python ecosystem. And again, you don't have to be a computer scientist or a software engineer to create these APIs. You really just need to know a little bit of R or a little bit of Python to create these APIs.

Thank you, Ryan. One thing I'll add too, that both Plumber and FastAPI provide that built-in Swagger interface, which is really great. So you can go in and you can test and play with and interact with your API. So that's baked into the framework already. So it makes it super easy.

I'll also say, this might be a future demo down the line, but for folks that are doing any type of modeling and have heard about one of our newest open source tools called Vetiver. Vetiver, one of the biggest advantages, you can take your model and you can very easily serve it as an API. Because you create these cool models, but how do you actually get those models in the hands of people that need to use it? Vetiver is a great way to do that. And it'll actually create a Plumber API for you automatically. It's really pretty slick. So I think that'll be a future demo down the line.

Closing and resources

I don't see any other questions over on Slido or in YouTube, except one was just some love for the embedded Swagger interface in Connect.

Oh, one question I think I maybe missed was from Tim. This is likely something we'll have to talk through with our account rep, but if we publish to Connect with no authentication needed, is there a limit we'll run into from public users?

Yeah, great question for your account rep. But if you have content and that's an API, could be a Shiny app, could be whatever, and it's set to anyone no login required, essentially opened up to the world, then there is no limit, really, in terms of who can access that, in terms of anonymous viewers. There are some things to consider for concurrent users as well, and that's gonna be a conversation you wanna have with your account rep. But if things are opened up to the world, anyone can use these.

Well, thank you all so much for joining us today. I wanted to share just a few resources that we've shared with you. So if you want to go to this link shown on the screen, pos.it slash demo resources, you can learn more about the products that we covered today. But if there is something like Tim just mentioned that you wanna talk with your account rep about, or you have questions for us that you'd rather discuss one-on-one, you can use this link, pos.it slash chat with us to schedule some time to talk with someone from our team. Or if you are just curious if your team is already using our tools, I love being able to connect teams within organizations as well, so I'd love to chat with you.

But thank you all so much for joining us today. As a reminder, these end-to-end workflow demos happened the last Wednesday of every month at 11 Eastern time. So as Ryan said in the beginning, if you enjoyed the workflow and would like to share it with your colleagues or your friends, we would love that too. And again, if you have any ideas for workflows or things you'd like to see, let us know as well. You can also just put that in the YouTube comments too, even with the recording. So this recording will be made available immediately as well as the blog post that just went live, so you can go jump in and follow along and use this in your own environment too.

Thank you, Ryan, Katie, and Ralph. Anything to add? Awesome. Well, have a great rest of the day, everybody. Thanks all. Bye. Thanks everybody.