The speaker discusses the addition of recipes to the SDK repository, categorizing them into business and engineering recipes to cater to different developer needs. There's an explanation of the SDK's dual purpose of providing functionality for integration and serving as a learning resource. The strategy of developing recipes across multiple programming languages is outlined, emphasizing both duplication and uniqueness across languages. The podcast concludes with a summary of the discussion and an encouragement for users to sign up and integrate with the API.
Summary
Introduction and Overview
- Opening greetings and introduction to the podcast topic.
Current Go SDK Work
Mention of ongoing work on the Go SDK and its objectives.
Explanation of adding recipes to the SDK repository.
Types of Recipes
Introduction of two categories of recipes: business recipes and engineering recipes.
Explanation of the content and purpose of each recipe type.
Structure and Functionality
Discussion on structuring the SDK to serve multiple purposes.
Explanation of the coexistence of SDK functionality and recipe content in the same repository.
Future plans to expand recipes into other programming languages.
Recipe Development Strategy
Discussion on duplicating recipes across different languages.
Explanation of the value of unique recipes for different languages.
Overview of the current progress and tasks involved in developing recipes.
Podcast
Check out on Spotify.
Transcript
0:01
Hey there, hope you’re doing well. In this podcast, I want to talk a little bit about the current Go SDK work that we are doing. I did mention that in one of the previous podcasts, and I’m going to continue. I don’t know where I left off, but I’m just going to pick up from where I think I left off in the last one of the last podcasts.
0:19
So, I mentioned that we have a number of endpoints we’re trying. We’re adding this first Go SDK on our first API that we published and went live on a week ago. So definitely check out developers.snowpal.com as part of the SDK. While the primary objective of that repo is publishing and creating the Go SDK, we are also intending to and beginning to actually add recipes to that same repository. So recipe could mean a few different things, but just for terminology, just to make sure we are on the same page.
0:57
Here is what we think of the recipes. A recipe is something that we’re going to publish, and as a developer, when you look at a recipe, there could be two categories of recipes, right? One is, we’re going to call it a business recipe, and the other one is like an engineering recipe. The difference between the two is that a business recipe speaks more about solving business problems, probably contract use cases because we don’t exactly know what your use cases are since our API is going to be able to cater to a wide variety of use cases and it’s very industry agnostic as well.
1:28
So we are going to come up with a set of use cases, some simple enough ones, and maybe have more complex ones as we progress. Those are business recipes. The engineering recipes would be not so business-oriented. It could be essentially if you took up something like Postman and you took a workspace and you took a collection and we have a number of directories where we have categorized our endpoints.
1:51
Each of that directory, let’s say there’s a directory that deals exclusively with key attachments, right? So that would be like different thread operations and attachments and functionality on key attachments, not key or block or pod attachments, for example, because we don’t support attachments on keys directly. Those would be, we are going to call them engineering recipes because collectively they don’t really solve a very specific business problem because they are not intending to, at least by way of the example, they’re trying to showcase the actual functionality of the endpoints more from a development standpoint.
2:24
So we’re going to call them engineering recipes. So if you’re a developer who wants to get a quick sense of how a certain endpoint works or a certain group of endpoints work or a certain directory works, the way we’ve categorized them on Postman or one of the other clients, whatever your favorite REST client is, you could start with an engineering recipe or look at them first. But if you’re a product owner or product manager, the business recipe might resonate better with you. Sure, both parties are welcome to look at both categories of recipes. That’s our ultimate goal. But your starting point could actually be different based on where you’re coming from, what your particular role is. So we’re going to add those recipes to the same repo.
3:04
So when we are structuring the SDK and developing, building it, we are cognizant of the fact that it needs to serve two purposes, right? One is the purpose that I have mentioned, which is essentially being an SDK. So you can start importing snowpal, the snowpal SDK into your Go repository and your Go applications and start leveraging our API. But also, at the same time, if you want to just learn and understand, get a breather, get a feel for the scope of what we’ve done and for the functionality it actually truly provides, then the recipes would actually be a better fit. Right now these recipes, given that they’re going to be living alongside the Go SDK, the initial recipes would be written in Go, but as we create more SDKs in other languages like Node or C# or whatever else, our aim is to actually build recipes for those as well.
4:58
Now, whether we’re going to build the exact same recipes from an SDK standpoint, it needs to be exactly the same. Other than the fact that the language is different, your SDK, its functionality and its versions and its dependencies are going to be quite identical. But from a recipe standpoint, not necessarily so, right? So when we have a set of recipes on this Go sitting parallel to the Go SDK, and we build like say a Ruby or a TypeScript SDK, we may have different recipes because the idea behind the recipes is that they collectively showcase our functionality uniquely to you and to help you get started, hit the ground running quickly, right?
6:27
That’s basically it. And hopefully, it gives you some sense of how, you know, once you publish an API, what are sort of the more natural next steps, right? SDK was a very natural next step. The recipe was also a next step, but we are trying to figure out which one to do first and then we identified that maybe we can actually do them together if we took this approach. And that’s what I want to share with you. Hope that helped. And definitely, you know, sign up on snowpal.com if you’re an end-user. If you’re a company, your software company building cool applications no matter what they are, definitely check out our API and start integrating with us. Yep, thanks. Talk to you soon.
Top comments (0)