API Gateway Series: Publishing Snowpal API (from start to finish)

AWS API Gateway. Snowpal APIs.

Jan 02, 2024

You may have heard about API-First strategies. What does it mean to build your APIs first? What is an API Gateway?

In this API Gateway series, I’ll be sharing a lot of those details. If you have an interest in doing something similar, I hope it benefits you.

1. Introduction

What are we trying to build, and how should we go about it?

0:01

Hey there, hope you are doing well.In this podcast I want to talk a little bit about API Gateways because that is the recent work we have been doing.We are about like 8085% there.So we have a bit more to go before we can get our first API product out the door.So we are pretty stoked as a team and we have been working on this for for a few months and on different aspects of it.

0:24

Right In this video I will just talk about one part of it which is once you have your endpoints implemented like your API that is the endpoints associated with a single API, what do you need to do to get out there right.So it could be little bit overwhelming because there is lot of options, there is differences and similarities between the different providers, API providers out there.

0:44

So this is if you are ever thinking about doing it.Given API first is pretty popular as a strategy and lot of companies are moving in the direction of publishing their back end.So folks can actually build their web or mobile apps or other server side systems that they can integrate with right?

1:01

Just to just to be able to focus on their core business and let some other companies do a lot of the heavy lifting right on on the server side.So in that context, without further ado, let me get into this video and and thanks for dialing in, if you haven't checked out our product, go to snowpile.com, download an app from the app and Play stores and that's basically it, right.

1:22

So let's get started.So you have in our case, we have our Snowpile API, the first API we are going to publish is going to be a project management API, right?Our API is very generic, but the first version of it that we are publishing is going to be project management, management oriented, if for no other reason, but simply for the fact that our web, our current product that's out there already in production has been there for for a couple of years, a little bit more than that now is as you know, a project management platform, right.

1:50

So we figured we built that pretty generically.So we were like why can we not take this and have other folks, companies benefit from what we have built and have things have a stable set of endpoints on the server side.So you can actually build something like snowball.com but to satisfy a similar business need, a different business need does not matter, right?

2:13

That is the essence our idea behind exposing, you know, wanting to publish this API.So the first thing you need to publish in API is the end points associated with and again I am not talking about this in any particular order.If you want to know the theory and if you have been, you know if you follow any of my podcasts or technical work you you hopefully know that you know I don't get as much into the theory as the practicality of how we use some things that I actually talk about here.

2:41

So if you want the theory, there's there's plenty of places you can look up online, right?So, but from a more pragmatic standpoint, what are some of the things you need to publish in API?The first thing is you need is a number is end points that you can actually that provide business value right?Whatever those end points are, whatever their the core business problem that you are solving is.

3:00

You need to have a set of end points that that you need to associate with the API and API is consists of one or more end points right?Whether it is REST end points or graph end points, our first API is going to be, it is going to comprise of number of REST endpoints, right, Exclusively REST endpoints.

3:18

Our future APIs will have you know will touch other, will you know impact other businesses, solve other business problems and they would be both REST graph depending on the type of problem we are solving and the nature of a consumers right.But the very first one is a set of REST endpoints.

3:35

We have a pretty large number of end points at that kind of powered the snow pile system in our first release.We are obviously going to you know just expose all of them.We should have probably we could have started with just a very small handful of end points because we look at lot of the providers out there at least from what I have seen they published like 15203040 end points.

3:55

Some large providers like Box, the largest one I have actually seen I I I do not know do not quote me on this.You can look it up.They have like a 101 fifty endpoints or something that is a pretty sizable number.Our first version of it again we we honestly do not go small in whatever it is that we do.

4:13

So our first API is going to have close to 400 endpoints.It is a pretty big number as you can imagine.I'll, I'll speak to you know more details about this but but it's suffice for now for you to know it should suffice.Know that it's an API that's project management oriented and it's got close to 400 endpoints.

4:30

I think the exact number is probably like 380 or 378 or something like that.And probably there's a few more that we need to add as we before we go live that the first thing you need is a set of endpoints that provide a piece of functionality.Now we only have that because our mobile app and our web app actually consumes and our mobile web, the responsive app as well.

4:50

They all consume those endpoints.Now the web app does everything that we everything that we support is exposed on the web app. 80% of what we support is exposed on a need of mobile app and we are going to keep increasing that making it 100% and also shifting focus a bit.So it does continues to do what the web does and a lot more in time in the immediate to the short to near term future, right.

5:11

So we have those functional endpoints.So then we are like if that is if you have them already, how difficult can it be to actually get them to publish them so other folks and other companies can actually consume it, right.It is taking me like 5 minutes or over 5 minutes to give the introduction to this problem that we are solving and to give you some context to what the video is actually about.

5:35

But it is going to take a little bit longer for me to get into the next set of details.So rather than spend more time editing the video because lot of these platforms I published around do not support more than a certain length of time and that has been a challenge, I am just going to say myself some Final Cut Pro time and stop this video right here.

5:53

Call it part one of North whatever N ends up being as far as the EPI gateway podcast is concerned and pick up, I will just pick up from the next one.Thanks for watching.Bye, bye.

2. Postman Workspace & Readme Documentation

Setting up ReadMe documentation, and creating manageable Postman workspaces. Postman is one of the most popular API development tools, something that developers tend to prefer. If you are a product manager, you are likely going to take a liking to ReadMe.

3. Gateway Deployment & Topology

This is one of the most important and early decisions you will have to make. What should your deployment strategy look like?

4. Backward Compatibility of APIs

While you are going to continually improve your APIs (by virtue of which it is bound to change consistently), remember to also keep them backward compatible.

0:01

Hey there hope you are doing well.This is podcast #3 in this API Gateway series.In the last one, you know the first one I give you context and the and some idea about the code problem we are trying to solve.And the last one we talked a bit more got in the details about README documentation about Postman Workspaces and Insomnia.

0:21

And then we got as far as the actual API gateway that you know we are building that we are hosting on AWS on AWS and using Lambda and all the serverless computer, right.So let's get into a bit more detail there.So in going so right now if you recall the last one or if I highly recommend you watch it before you get to this one.

0:41

I talked about a notion of pre and post processes at the endpoint level and that the overall requested responsible, right.So that is one of the value add that the gateway brings to the table.There is plenty of other requirements for the gateway right beyond beyond the typical requirements you would expect for a gateway to do or to have or to satisfy.

0:58

There are very business specific requirements at this this particular gateway or any gateway is going to address essentially, right.So 1 is OK, how do I, you know the the we already talked about the processing pre, pre post and whatnot, right?Those are hooks if you will.In other words Now on top of that, let's say the the client makes a request and they I know, let's say they're calling slash keys to fetch a list of keys from our system.

1:26

Now a different client might actually want to call slash projects, right?And again I'm kind of jumping the gun here because in our first release this is not something we are going to we support but we may or may not take the the effort to to sort of publicize that because you know we we have enough other fish to fry.

1:44

But this is all you know actual value add that is part of the core API gateway that we are building.There is different, let us say there is a different client that who might want to use it who might actually benefit and of benefit is the right word.Maybe they like a slightly different language, right.

2:01

And again the API is going to be consumed by companies across the globe.So again there is this regional and differences in just in just the English language, lot of the API, the API have seen API documentation they don't they don't seem to give you that option and while you could argue it's a nice to have, I think it's it's a little bit more than a nice to have because sometimes if it speaks your language, it's much easier as a developer, as a product owner to consume and understand what it's doing right.

2:27

When I see slash something, whether it's slash employees or slash projects or slash keys or slash restaurants or slash planes, I think that it's if I'm a plane company, I'd rather it say planes than like trains, right.It doesn't matter.I can probably draw the parallel or you know, connect the dots, but I think it makes it easier.

2:44

So one of the features that we have supported in our gateway is the notion of aliases, right, which means it's very internal, right?It's not so much public to the end user.Eventually we would publish an endpoint in multiple forms, maybe we call it slash keys for the community that understands our existing language and verbiage.

3:06

And they they, they see eye to eye in terms of our terminologies, right?Or glossary.It's not about glossary so to speak, but what if you like the word projects better because it's it's maybe it's it's it's a much simpler English word and it's not domain or company specific, right.

3:21

So you could you might want to call IT projects or you as a product owner would understand and get the gist of it.But you feel like you're developers and given the context of what your team team is doing, you would you prefer that it be called something else?Now we've built that functionality into our gateway, so you could basically we we would expose that using a few different aliases, right.

3:42

So let us say I would say slash keys or slash projects or boards or or views or whatever it is essentially.So when you are consuming it, it, it speaks a bit more of your language, it speaks to you, right.That is one feature We have a a very specific need for which we actually implemented this.

3:59

But this is sort of the side effect benefit if you will, right?It is more than a side effect benefit, but but hopefully you get the essence of what I am trying to say here.That is one feature that the gateway supports next in terms of let's say when when the gateway gets the request, it needs to determine where to forward those requests to, right?

4:18

So now let's say there is going to be a number of micro services behind the gateway right?That is not Privy to the end user, the end user in this case, being a developer, a dev team, other systems, apps, what not, right?It is not Privy to them.But we know that if this request comes in, it is asking for a cup of tea.

4:35

I may need to route it to a micro service, right?Let's say we started the food micro service because maybe it is small enough that it was part of, you know, food and maybe there is another travel micro service, right?Let's say we only have two micro services, but let us say tomorrow we we grow enough the, the API grows enough from a food standpoint that we have enough beverage consumers or companies interested in integrating with it, right.

4:58

So maybe we then decide you know what maybe tea needs to be its own micro service, right, Maybe coffee its own micro service.And I do not want to try wine because as in wine is like a generic commodity.Unfortunately I cannot tell the differences between them but I am sure if you get into the world of wines this probably there could be different micro services for different types of I don't even want to try it but different types of grapes or or which part of the world it's coming from right.

5:22

Anyway so but it but you get the idea.So there's a tea micro service and a coffee micro service and maybe some other food micro service.Right now if the gateway gets the request for list of get me the list of green teas versus give me the list of restaurants or food related items that's not tea or related to tea, what if you want to reroute it?

5:42

Again, I'm, I'm kind of completely manufacturing these examples, but I'm only hoping it, it sends the message across because our requirements are very, very specific to business problems and I could express them here, but there's two challenges there.

5:57

One is it's giving away a bit more before the movie is out.So we are like 15% we need, we have some distance to cover.And two, it might be a little bit too specific, maybe right to our problems that maybe it resonates with you, maybe it doesn't depending on your industry.

6:14

So I'm trying to come up with these generic things that maybe that sound a bit more fun and less serious.That is the essence of me taking these random examples.So the API Gateway is going to get the request.It's going to make a determination based on the how it makes a determination.This is a topic for another video, but let us say there are some rules that define it could be regex, as simple as that, or it could be more complicated rules that define how this routing needs to happen.

6:39

So that intelligence is going to be embedded into the gateway, right?Whether it's the same Lambda, likely not, right?It's going to be multiple Lambdas that live that make up this ecosystem of the API, AWS Gateway, but regardless it's going to go to the gateway and you can think of a gateway as, let's think of it as a big circle with the number of AWS services.

6:58

Now we don't believe in Wendel Ocken, so it's not all of them being in AWS, certainly not.But you know you got to drink the kool-aid to some extent.If you're publishing in a certain platform, you don't want to fight the tide, right?If you're paying it's, you know, it's like paying quarter million for like a Oracle database or something, isn't that that expensive?

7:14

Then you want to use, you know, all of the analytical and other functions that Oracle provides you as opposed to arguing that I'll stick to ANSI sequel even after paying like what, a million for Oracle, right?If you're paying the kind of money, use what they give you.Otherwise, just go with my Sequel or Postgres, which probably anyways, you should actually go with one of those two anyways, That's besides the point.

7:33

So the gateway is going to have some intelligence built into the routing and make some decisions based on that.Then going to say, hey, you know what, let me send this to the tea service versus the coffee service versus the food service, for instance, right?That's one more.I think I only mentioned four or five features that make up the the, the API, the gateway.

7:51

But I'll keep going as as long as I can remember from the most recent things we've done this week, that is the massaging of the response back.Right now you make a request to get a list of projects.The language that we speak internally at Snowpile is going to be different from the language we want to expose to our end users.

8:07

So there is certain amount of there is an element of massaging that is required and that will be done by the API gateway.Now some of a lot of that massaging is going to be API agnostic like endpoint agnostic, sorry and API agnostic.But there are certainly going to be some, there is going to be some logic that might end up being API specific even if not endpoint specific, right.

8:29

So the tricky part here is to determine where the line is.Where do you draw the line?You don't want to make changes on the code API.You do not want to make changes on the code API server if those changes are not generate to a lot of your consumers, right?And then what happens to existing systems like our own products and apps that consume those endpoints?

8:46

We don't want to have to redo any of what we've already done which works just fine to satisfy the differences, the nuances that this new architecture is going to bring the to the table right.So backwards compatibility at the top of our requirements list from a core API standpoint.

9:02

So the massaging a good fair amount of the response massaging is going to happen on the AWASAPI gateway.So that's maybe is it like five or six.I can I lost count in terms of the features that it brings to the table and close the 10 minute mark.So I after end here to be able to publish the video on a lot of the other platforms without me having to do the editing.

9:22

That's basically it.And this video will pick up from video #4 in this series in the next podcast.Don't forget to sign up on snowpile.com and you know, solve problems better, right?That's what we are here for, users solve problems better.Thank you.

5. API Monetization

You have architected, designed, and implemented your APIs, and it is now to time to start selling them.

0:01

Hey there, I hope you're doing well.This is podcast #5 in the series of APIs and API Gateway.In the last four, we talked about a number of different things.This is quite a bit that we talked about.So I'm not going to just you know jog my own memory or yours unfortunately.

0:19

So please go check it out.But I know where I left off in the last one I left off saying talking specifically about a lot of the features of the gateway does support or will support our gateway and gateways in general.But I was speaking to our gateway which which does quite a few things.So hopefully you can check them out and benefit from it.

0:35

And in this one I said we won't go, we are going to talk about API monetization, right.This is a broad topic, but let me get into the aspects of API monetization that we have actually had to learn and get into during the course of what we are doing for our first release, right.It's going to change, it's going to keep evolving I should say.

0:52

But you know we have a way that we know we are going to monetize that in our first, first release.So you are going to once you have an API and you have a number of endpoints, how do you make money, right.There is many different ways to making money, but one most obvious way make to making money is you publish the API, you charge per request.

1:09

You are going to say, hey I have these endpoints, I am going to price them exactly the same.Every endpoint is going to cost you whatever it is that is going to cost you, right.I think typically it varies between, I would say, I don't know, 6 to $12.00 for thousand requests, something along those lines, right.

1:26

I'm sorry, 6 to $12.00 for 1000 request, correct in that range from what I've seen.So you price it at the at the request level, which means every request you give a bunch maybe 100 free credits for 100 requests and then after that you start charging, right?And it's basically the even charge.That's one way of doing it, the simplest simple way of doing it.

1:44

But there's other ways.There's number of ways you could do it and you're going to have to keep tweaking and altering as you learn from your customers, right.Some providers give you N number of credits for free to begin with, like I mentioned 100 or whether it's 500 or whatever that number calculates to.You know after those credits they have a subscription, right?

2:02

It kicks in.So you need to pay for a monthly subscription or maybe an annual subscription for every.They have number of plans and each plan gives you an X number of credits and maybe there are over 8 charges.If you purchase the basic plan and give you 1000 API endpoint request or 1000 credits and let's say each request translates to one credit.

2:21

So you have 1000 requests that you could make across all Http://verbs.I'm talking REST endpoints but you can you know, sort of explain extrapolate this to graph as well.Then after thousand after you exhaust those those requests you either could get charged overages or you would have been you know you have a bump, go to the next plan for instance, right?

2:41

Or maybe it doesn't even serve your request.However, you want to facilitate that, right?So you're going to say you pay so much, you pay more after the thousandth request.Or you go to the next plan, and in the next plan you're going to get 10,000 requests right before you get.And your charge, your cost might reduce per request.

2:56

So essentially, if you charge $7.00 for 1000 requests in the first plan, you may charge $6 for the next 9000 requests or something, right?So you get the idea and that's one play.Tiered pricing, there's a number of it's again, it's an art and a science mixed, right.It's a mixed bag when it comes to pricing of anything for that matter.

3:15

So you can check it out, see what works best for you from a pricing standpoint.We have a way we are going to price our endpoints, which you know it.We are going to, you know, support plans and whatnot.But we are going to start quite simple because all of our energy, 95% of our energy is spent in actually getting the API available, working in functional stable and performance out there to our consumers with our pricing plan.

3:39

And then we're going to spend a little more energy trying to improve upon our pricing strategies as we launch more APIs and release more versions of our existing APIs, right.So that's monetization.Now, how do you go about monetizing this, right?Again, there's probably many different options and here is what we are kind of going with.

3:55

So it's a direct, practical, pragmatic example.AWS Marketplace is one of the first places we will be publishing an API to, right?So in the last videos, I talked about the Gateway's functionality itself that is different from the marketplace, right?When I say API Gateway on AWS, that's the core functionality of the API and the Gateway's existence itself, where it's being deployed to, right, using serverless computing and whatnot.

4:19

Yeah.The AWS Marketplace is where you have to monetize.So essentially, you're going to publish your API on the marketplace.So much like you go to Amazon.com to find the product, you're going to go to the AWS Marketplace to to consume other services offered by companies.You're going to look for Snowpal, you're going to click subscribe and then a number of things happen behind the scenes after which you will be given an API key and you will use the API key to make your request.

4:45

And then based on the plan, the usage plan that you are associated with that you actually picked when you subscribe, you are going to be charged, you know at that rate essentially, right.So that's that's a pricing model.We talked about pricing.We talked about the user experience that going on boarding, this is the on boarding experience.

5:02

You go to AWS Marketplace, click subscribe, find snow pals, subscribe and then you get an API key by e-mail and you start using the API key.You go to postman, download the, download the workspace, stick the API key, replace the environment variable with the actual API that are sent to you and then you start making requests and you're good to go.

5:20

As simple as that, right?That's how simple your experience is going to be.Now you can start.You can start focusing your energies on building your app, mobile or web or or server side systems or back end applications or whatever it is that you're doing now.You can focus on your core business problem and not worry about, you know, the the underlying sort of the the the functionality, the boilerplate stuff, if you will, right?

5:42

That you do not have to build.How do I sign up?How do I sign and how do I do social media?Sign up using Microsoft or Google or Facebook or Apple or or even just e-mail.Password sign up.Resetting passwords, creating projects, keys, more content just for doing everything we support on our system.

5:59

You can start coding in minute 10, I should say, right?It should be literally as simple as that.And we expected for it to be as simple as that.Even starting our very first release.Because we are all developers and we treat ourselves as though we're not providers of our own API to just kind of understand the end user experience and where there will be gaps, you know we're going to fix and address them as we go.

6:24

That's monetization.Option one is AWS Marketplace, right?The 2nd is now you're going to say you, what about systems like you've probably heard of Rapid API, they rebranded themselves and I believe they call themselves rapid now.I still think of them as Rapid API.A lot of the internal language hasn't changed either.

6:41

They have a marketplace where you can publish your API.Now that is an option and we will very well, you know, we might end up doing that, but that's typically it's like a large marketplace, I don't know how much wetting if any they do at all.So it's hard to tell the credibility of the providers right now.

6:58

We exist as a company registered in the US, been around for years.Our systems are powered through our endpoints and I'm doing these videos.We see a lot of our content and writing out there.So, you know, we are legit, which may or may not be the case for everybody that's publishing out there.And there's been a lot of simple fun endpoints too that some developer wants to publish.

7:17

Great.They want to check it out, they publish, right.But it doesn't provide any value, any meaningful value to anybody.So you can build your system based on that.And even if you did, how do you know if these endpoints are going to continue to run, what the SLA is, how they scale and all that kind of stuff.I could be wrong, but I don't believe from my understanding my conversations with happened so far if they would actually ensure that from a public marketplace standpoint, which is why they actually have Enterprise Hub and they have some something called a business beta hub which we are in talks with, then we might end up actually leveraging that.

7:44

So that so there is a public hub, it's a marketplace which may or may not fit our needs.And then there's this enterprise hub which is for much larger organizations apparently that have hundreds and hundreds of APIs.We will be there one day but not there yet.So our needs are not there and also it has functionality that really doesn't benefit us in terms of what are we trying to do initially or for for a bit.

8:05

So the business hub that they are going to provide, which is going to be in beta, which I'm kind of eager and curious about because that might suit our needs it you don't send somebody to the market rapid marketplace when they check out and you don't expect people to find you there as well because the search engine optimization for what I've seen on Rapid has been very poor to say the least.

8:23

I've never ever searched for anything from an API standpoint in Google.On Google, that has redirected me to the rapid marketplace, right?That's something they probably will work on, one would hope, but it's not there yet.So you'll have to go rapid and then do the search.Which means somebody needs to know their system and their existence already, which is an if.

8:40

But even if they do, I don't know how their search response, what the algorithms are, whether which API is at present where credibility shows in there, how many endpoints Slas it can get as complex as you can imagine.While I don't know the exact answer, I have no reason to believe that all of the intelligence is built into their search at this point.

9:00

So just publishing it there and expecting magic to happen, you would be wasting your time possibly, right.So that brings us to the core next part in video number.I want to say it's probably 6 I lost count in the series.We'll talk about what other options that are out there or what Rapids business Beta option is business app that actually could help companies such as us publish your API to the larger world out there.

9:24

Thanks.And don't forget to check out snopal.com.Thank you.

6. API Hubs

There is no dearth of API Hubs but you are going to have to select a couple to work with.

7. API Documentation

Needless to mention, the pace of adoption of your APIs is going to be proportional with the quality of your documentation.

0:01

Hey there, it's video #7 in this API series.I had no idea how many it was gonna take, but I didn't know it was gonna take this many to be honest with you.And the last one we talked about some of the API hubs and providers like I know Blogger and AWS Marketplace and Rapid and Kong.

0:19

I talked a little bit about Kong just to continue going to look more at Kong to see their pricing is much higher.So again how does the how does their pricing work?We talked about API pricing in your plans and tiered plans and subscription and endpoint request costs and but we didn't talk about how, how they charge you, right.

0:36

So like with Rapid API, the public hub is public hub is has no subscription but they charge a flat 20% fee on all of the request that goes through them.Blobber charges you, they have couple of different plans.The initial plan is like $100 and per month or 99 per month something like that.

0:54

You get a certain number of request and for every request they take 10% Commission, right.So that is their pricing model.Kong, I think I believe it is like $250 a month or something like that.And I do not know how much exactly they charge for.Oh, by the way, since Kong, with Kong, you may the request may or may not go through them, at least in the plan that I've initially seen, they may, they may not be a charge at the request level.

1:19

So it may just be a subscription that you actually purchase with them, right, like a monthly or an annual subscription.So that's the cost that you have to absorb and then you charge your consumers and then you, you make the profit right at the margin for the value added you're bringing to the table essentially.So pricing is your own, your own strategy.

1:36

You have to figure out what works, what are the different options.You're going to have to be able to provide on different systems and then onboard your customers, right?So onboarding, offboarding, there is similarities between these systems, but there are differences as well, so it's left you to how you want to handle them.

1:53

If you're small and you want to start quick, you may want to publish 1 endpoint, 1API1 endpoint and one provider.Or if you like us, you might publish 400 endpoints and like 3 providers, right?It's more power to you.Whatever you think you want to do or your team is capable of, you should lift as much, but don't chew more than you can buy it, right?

2:10

As they say.So that's that's in terms of the API hubs and provider options that are out there you get.Now let's let's jump gears, let's go to how you set yourself up on these systems.Most of them support an open API import, whether it's read me for documentation or if it's these other providers to to publish your endpoints.

2:32

So you can try those endpoints out.You could as long as you have an open API yaml, you can.I think Swagger Hub is another option as well, right?I'm sure you're familiar with Swagger, so you can import your open API yaml and publish to these systems and then as long as it is valid Open API specification like 2 dot O or three dot O you should be good to go.

2:50

Some of them also support Postman so you could use that as well like import postman importing postman collections.But be wary because there is bugs all over the place with Rapid.I do not know whether they have changed the infrastructure or they are making some improvements.I have run into a lot more bugs and I have run into with Rapid in the past.

3:07

So I have not gotten the sense of stability with their systems, but you know maybe they're evolving, maybe they've, they've had some challenges that we had to wade through.But I I strongly believe they will get past these challenges, right not I have no idea, but I'm hoping and I trust that they will.

3:25

That's all I can say, right.So when I imported it into Open, imported Open API AML into RAPID and I when I imported the Postman collection which is which is identical to Open API.And we'll talk about how how you can do transformations between those formats right.

3:43

Given the bugs that Rapid has the the documentation that that you see after the import happens is actually quite different.There's some there's some glaring differences right like we have in our Open API, we have like titles and description for our endpoints that we enhance after we publish a lot of these platforms.

3:59

But we have a core, a basic, very basic developer documentation that we publish.When I did that on Rapid using Postman versus Open API, I noticed the I think it was with Postman or the other, I can't remember, but I think when I imported the Postman collection, the titles were completely missing, right.

4:16

It actually used the endpoint path as the title, which if you have 10 endpoints of 20, it's now no biggie, you can go updated if you have like 400 or three 75378 like we do, We don't want to, we don't do anything manually right.Everything that we do not only should our end, our API scale for the end users and consumers as businesses, we want our internal processes and processes, whatever the right way to pronounce the word is to also scale so we are optimal and efficient as as members of the team.

4:45

So that that is the there is this challenge.There is some differences but most of the other systems then have very many bugs.So we were able to import the open API YAML and then we can make improvements to these.The documentation as you go essentially right or we are going to like I said we are going to have richly documented endpoints.

5:03

Rich is subjective word as rich as we can and time allows initially and then we keep improving on it on readme and the other ones might have some documentation.But just pointing you to readme if you want to learn bit more about what we are doing right.Because on readme we can add screenshots of snobile.com, the mobile app, the iOS app, the the Android app, the actual web app, maybe the mobile web version, all of those we can have actual product screenshots, user interface, UI screenshots, code, R code exposed like few lines here and there.

5:33

So you get context out of consuming these endpoints.Maybe you have recipes, I mean I mean you can do whatever you want there's there's a gamut of things you could possibly do and we would be doing as we actually improve and stay focused on our API work this year, right.

5:50

So that is from a documentation standpoint now to create the postman.The one of the most interesting things that we have done initially was we have a lot of these endpoints we want to be able to create them or like postman publish them initially on the postman workspace, right.How do we take what we have, We were we were essentially using Insomnia.

6:08

Insomnia is great, but they do not respect or confirm the Open API specification.Unfortunately, I have no idea why.There are some tools that do the conversion but do a very sloppy job, so I don't know.I wish they had a way to convert or publish to Open API spec, but they don't support not that one I have seen as of the moment of this recording.

6:27

So we had to do something to actually convert it, right?So this is here is what we did.We wrote a script that essentially takes our endpoints the way they are right now and actually creates the Postman workspace right.So it was done not manually but through a script.

6:42

So every time we make some changes we run that script.We have our endpoints defined as YAML file.So we have, let's say, the phone and endpoints defined in YAML in the number of yaml files as endpoint specifications in the code.That code comes into play at runtime as well for actually doing the mappings and transformations and pre and post processing.

7:01

But the exact same mapping also feeds into the script that can be run when you want to convert.When you're making changes to an endpoint or you're adding or removing an endpoint, not removing adding endpoint or modifying endpoints or whatever.You run the script so it spits out a Postman Jason and then we import that into Postman or we have this like NPM plug in that we use which transforms that Postman Jason.

7:24

It's got a couple of bugs, but it works for the most part, transforms that Postman Jason to an open API YAML and then used to import that open API YAML into these different API providers.Now since our script already converts that into Postman, a lot of these systems support Postman.

7:40

You could choose to do that, but not all of them have seen support Postman and not gracefully so.And again, it's not an, it's not a specification right?It's very proprietary right?So we don't want to get logged into that even at that level.So we do all of the transformations using the NPM to the open API, open YAML, open API yaml 3 dot O specification and then we import that into these different API providers.

8:06

That's our process.We do it repeatedly and it works quite seamlessly.And so whatever you know improvement we want to make to our documentation, we'll do it after the fact, after we do this import into those systems.At that point we're going to keep read me updated, right?

8:22

But we don't want to keep we're going to because we're going to have more people, other people, non-technical people or partially technical people update these this documentation which means they'll never make it's way into the code where the YAML is defined with those endpoints where the initial documentation was.

8:38

So we are not in a position to re import this, at least to read me because then we would lose any additional work that was done.So ideally you want to say that you want to do all of our documentation on the YAML so this process is repeatable.It is repeatable, but to some extent right?

8:56

We do not care for it to be repeatable on this richly documented README site may be everywhere else we can continue to use the process, which we will, but may be on README we might just import a transform a subset of those endpoints or code actually the script actually supports.

9:13

You can tell which file to go to which endpoints or which endpoints to avoid.It only creates the Openml for that and then we can merge this alongside the other ones that are out there.There's a few things involved there, but we can't do it to continually keep our documentation rich and published, right?So that's as far as the documentation is concerned.

9:32

There's a little bit more, but I'm going to end this video right here.Thank you.

8. API Gateway

Our APIs are deployed on AWS API Gateway and if you are an AWS customer, it is a natural choice. While there are differences between Gateway providers, there are plenty of things which are in common. So, once you understand how to deploy on one Gateway, it should be fairly simple to deploy on others as well.

0:01

Hey there, this is podcast #8 in the series of the API Gateway discussion.It's been a long series, but it's been a brain dump of everything we've done in the last several months to getting as far as we've gotten with the Gateway. 85%, ten, 15% more to go, hopefully in the next few weeks.

0:17

Fingers crossed, and my hope is all of these videos collectively help you do whatever it is that we are doing even faster than we were able to do, because a lot of this stuff is out there, but not collectively so, right?So this is like a concise, succinct, at least to my extent, right, a summary of everything that we've had to do.

0:35

So this is I believe it's podcast.In the last one I don't remember we talked about a number of different things but we ended the the monologue there with talking about open API format and Postman format and how the differences and the import into these different API providers.

0:53

Right.So once you import into these systems now you are good to go right?You want a process where you publish different versions of your API and and add different API's as well.Now depending on the plans you purchase a lot of these providers and read me documentation is is it is expensive I believe read me only gives you like 5 versions of an API which to me it seems like a rip off but what can you do right there there documentation is the richest I have seen their platform when it comes to documentation.

1:21

So we are going to have to, you know, absorb that cost.So the more API versions you have, the higher plans you probably need to purchase and more APIs and so on and so forth, right.So the plan is we're going to start with an API with the large number of these endpoints and add more APIs, more endpoints, existing APIs and whatnot.

1:37

So there will be more versions, there will be more APIs.So as you get the key, your API key will not change if you continue to consume the same API.But for every API that we publish, you're going to get a unique API key that you will use.So now you could be a snowball API consumer that uses one API, most endpoints in one API, some endpoints in one API, most endpoints in most APIs, some endpoints in most APIs.

2:02

You know you pick and choose, right?That's left to you.But ultimately, you are going to be consuming these endpoints and benefiting and saving time and energy and be more productive.But that's what your end user experience is going to look like and where you consume our API because we are going to publish it on more than one provider, it's literally left to you.

2:22

Now when it comes to marketing and advertising an API, there is a budget.As for everything else, we are going to have to focus and make some decisions on where our ad dollars are going to from an API gateway standpoint.So it's likely you might discover 1 gateway before the other, but that's not to say that the gateway that are the, the provider that you find us in is not the only provider we're going to be on.

2:44

Definitely not, right?We're going to be there in a lot of different places.How much, how differently you know, only time has to tell essentially, right?So I've talked about a number of providers.There's even more like I saw one called Open API Hub.I think they are also very similar.

3:01

They have got their own differences, some of them the UI and the user experience.As for us to publish as a provider is a bit richer than others.I have not yet taken a liking to Open API Hub, but maybe they provide some value that I have not spotted yet that is different from the others.We only have.We have to see.

3:17

But so far we have a good sense of where we want to be and we are.We are almost already there, right?We just, you know, ironing out the last 15% of what we need to get done.We.So just to summarize all of these podcasts, right, that is in the series, we have talked about the gateway, we talked about Lambdas, We talked about the not architecture in detail from an AWA standpoint.

3:39

That is getting into the weeds of our implementation, which I am certain, I am sure I want to do, but probably down the road.But we talked about API monetization, API hubs, we talked about the different providers out there.We talked about the pricing models that you can pick and choose.We talked about the core APIs that these gateways will connect to.

3:58

We talked about round Robining.We talked about you know different microservices, we talked about data massaging, we talked about proxies and non proxies and some requests being processed in the gateway versus others being propagated to your systems, maybe other third party systems.

4:15

But but does that cover everything that we have had to do?Absolutely not, right.But it covers a good chunk of it.And if you've watched all of these and you still have questions, then I actually deserve to answer those questions for you.As long as I'm convinced you watched each and every one of these.

4:32

And if you haven't, that's fine, you know, take your time to because this is a lot of stuff here.That's I think that's essentially it for now, right?There might be more, there not might.There will be more coming in future, maybe even in the near future, maybe even 2 minutes after I end this video.So I think this is a good point to sort of wrap up this this lengthy podcast that has been split into multiple videos.

4:55

Don't forget to sign up on snowball.com as an end user, Download our mobile app.Need a mobile app from the App Store if your iPhone user or Play Store if your Android user.Or in the next few weeks, Fingers crossed, you can also become a business user and start consuming our our endpoints and API and then build something as cool as Snowpal or maybe even cooler than snow power.

5:17

Like more power to you right?User endpoints solve your business problems better right?A whole lot better than you might be doing today.Thanks for watching.

9. OpenAPI & Readme

Let’s talk a bit more about publishing your APIs.

0:02

Hey there, hope you're doing well.If you're watching this podcast, I highly recommend that you watch the eight podcast.There's a long #8 podcasts preceding this and relate to the API Gateway.You don't have to watch all of them.Maybe you want to watch some of them to get a bit more context to this.

0:18

In this video, what I want to talk about is a very specific issue, right?So let's say as part of our API Gateway work, the work that we're doing which is, which is going to be live in the next two to four weeks.Fingers crossed.One of the things we're doing is publishing our API spec on README, right?

0:36

And README is one of you know is a great platform to to publish API documentation.You're going to have it in other places, but README is one of our probably the first places we're going to ask our business users to go check out to get acquainted and acclimated with our APIs.So you can check out README, but anyway, so the way it works is you create your open API specification and then you can upload that onto readme and they suppose that you can either hit upload and do it via the UI or they have an NPM plugin that you can install and then do it through that.

1:09

So you just need the API key and you have the version number and you associate with that.I don't know the every the second version going forward, how that is supported on their web interface.I'm pretty sure it's very similar, but since the first time we've we've uploaded it there through during the course of our dev process, we generally use the command, the command line to publish newer versions, right?

1:31

So they have the NBA module and then we'll give it the version number.Let's say the first version is V 1.0 is their default.I don't know how their minor versions work, but let's say it's V 1.0.0.You can update that and you want to publish the next version.From what I've seen so far, you cannot do it from the command line and specify this new version number because it it complaints that that doesn't.

1:53

The version doesn't yet exist.So that tells me that they expect you to go to the web UI, the interface, and create the new version.And then you publish this spec, the current one, as that new version that you just created as.So you kind of create an empty new version, sort of a skiffle area.

2:11

And then you publish your spec that populates it into that into that version.Now to get to the core of what this video is about, you have all of your, you know, API definitions, request request bodies, descriptions and responses in here, here.

2:27

A lot of it in the Open API specification, because you cannot upload a open if you expect to read me and make any changes that are part of the spec in itself, right?They don't support that.They expect you to have made that in the spec and then upload it.However, whatever the means of upload happens to be, that's agnostic to the core item that I'm referring to here.

2:47

So what that means is you need to make sure you're pretty happy with the way your spec looks and then you upload that spec.But then they provide more ways to document your endpoints on top of what you would have done through the Open API specification, right?So let's say my endpoint says get all treadmills, right?

3:04

I see it's a GET request, it's slash whatever snopel.com/treadmills.We return a bunch of treadmills that are available to you.So that's a simple example, right?But now if you want to document the response and in this case it's, there's no program necessarily.

3:20

But let's say you want to get a particular treadmill, like the Nordic Treadmill.You then get do a slash treadmill slash.I call an ID.Their ID is a patch param, right?In other cases you might have query string params and then you may have request bodies for like PUT, PATCH or POST request.In any case, you're going to document all of them.

3:36

It looks good and uploaded.You cannot make any more changes to it via their platform, right?So you need to do it in the spec.Sure.So you figure out.I mean nothing to figure out.You do it.It's a little bit inconvenient.I wish they supported it, but they don't, right?And I can just speculate as to why they may or may not support it.

3:51

You upload the spec.After that you want to make you know you want to make additional modifications, enhancements to supplement sort of what your current documentation is.Maybe you want to add some screenshots, maybe you want to add some code snippets and whatnot, right?All of that happens to it needs to happen on the read me platform.

4:09

That's their value add that they bring to the table.Now the tricky part here is I don't know how much light is here, but hopefully you can still see me.But let's say I had a rich description there.I did some screenshots, code snippets, and a bunch of other things.What happens if you publish a new version of the spec?

4:27

I was like wondering what's gonna happen to what I did after I published the spec or uploaded the spec to the README platform and then I added more documentation around those endpoints.I I was hope.I mean, I mean I would we were hoping you know that it would preserve it and it actually does thankfully.

4:44

But but there's there's some nuances there, right?How does it preserve it?I mean again I'm going to speculate how the implementation might be.I have no idea, but I can take a reasonable calculate, a reasonably calculated guess at that.But the thing I want you to notice if you did some rich documentation and then you publish the spec, but you change, let's say it's slash treadmill slash colon ID.

5:05

And I took a lot of pain to add some added some photos, some code snippets, some recipes and examples and whatnot.And now I decided I'm not going to call it slash treadmill slash colon ID for whatever reason.I'm going to call it the pad is going to be slash treadmills slash Nordic slash ID because I want to now kind of categorize the treadmills by their brand, by the make, by the models or the company that makes them.

5:29

And I want to, you know, sort of have an ID following that completely concocted on the go on the family example.So take it with a grain of salt, but if I were to do want to do that in my next version, sure, from an API support standpoint I need to make it.We need to make it backward compatible and all of that stuff.

5:45

But ignoring that it's not relevant to this particular problem, let's say we make the change and then we publish it.You know what had happened?The the description and everything else that you added, the screenshots and the code snippets that were associated with this endpoint in the previous version, They would just disappear.

6:01

And if you did not, if you did not create the second version and then publish this new spec as the second version, you would have almost lost everything that you did.Which seems pretty scary to me.We just spent an hour or so trying to figure this out.So if I'm wrong, I'll correct myself in the subsequent videos from From what?

6:17

But from what we've seen so far, there's nothing that tells me that we may have gotten this.You know this this wrong at this point.So which means you either maintain the the URLs, the path to your endpoints, in which case thankfully it maintains the the content and the description you added on read me.

6:36

But if you change the URL, you're toast right now.You may not have to change those, and you probably won't do it all the time.Understood.But the fact that this happens is a little bit scary and I don't know, I have been you know, the kind of people We read through tons of documentation before we check something out.So I don't know if they've documented this.

6:53

Maybe they have.I want to give them the benefit of the doubt and believe that it is, but it's it didn't stand out to me.They didn't like it.It's not some even the reading we've done in the playing we've done so far, nothing told us that this would have happened.So we had a, you know, we had a requirement, we tried to satisfy that and we asked ourselves some questions and this was one of them.

7:09

And the answer to the question was something we figured out ourselves.And I want to share that in case hoping that it benefits you if you're in the business of creating or publishing APIs now or in future, just keep that in mind.So I just stick to the same endpoints.Or if you need to change the endpoints, make sure you publish that as a new version, which you might still do regardless, but there's nothing that stops you from overwriting the existing version.

7:32

You're welcome to do that from a command line standpoint, So just be cognizant of that.And if you end up publishing a new version and you lose because the endpoint URL changed, you lost what you had written down earlier.You'll just have to go back to the previous version and then copy, paste and mimic whatever you had in the previously.

7:51

So just something to note, it's very specific, but it's a reasonable enough problem that a lot of us might could would stumble into as we start publishing more APIs, more versions and what not right?And and if I find something that's in their command line, something that sort of warns us about these types of things, I will share in my subsequent videos.

8:10

And hopefully this this helps you if you're in the business of doing something similar to what we're actually working on right now.That's basically it for this video.And I just realized that I forgot to just use my headphones and the lighting is not great.

8:26

So the production quality, I don't know, but hopefully the quality of what I've shared in terms of the problem and the solution that we've actually been able to arrive at is something that is valuable to you.Thanks a lot.And remember to sign up on snowball.com, check out our mobile apps and then very soon you can build your business on our API platform.

8:46

Thanks.Bye, bye.

10. Testing API Endpoints

There are a few different ways you can do this, and in this video, I will talk about how we specifically do it.

0:01

Hey there, I hope you're doing well and if you're living on the East Coast, like near the DC metro, you're enjoying this unusually warm and nice day.It's like, you know, high 50s or low 60s in February, so it's brilliant.Without further ado, let me get into this podcast.

0:17

This is, I want to say like Podcast #10 in the series of API Gateway Podcast and I'll speak to the current work that we've been doing in the last week or so.So we are actively working on testing our endpoint, each and every single one of our endpoints before we go live, hopefully the next three weeks, fingers crossed.

0:35

And we're going to be publishing our API on multiple hubs like I've mentioned the previous podcast.But the endpoints are sort of like hub agnostic.There are some nuances to how we're going to publish them on different hubs, but outside of that they are essentially the same endpoints providing the same business value regardless of which API API hub you come through as a subscriber, right.

0:56

So we are testing the endpoints currently on AWS Marketplace, essentially doing it through Postman.So we go through these endpoints and here are some of the challenges we have, we are running into.We found some solutions and workarounds to to sort of expediting our work.

1:12

But these are some challenges that we've run into and most likely you might run into as well.So hopefully this this helps you.So let's say we have, we have about close to 400 endpoints.Forget the number, just take that as a sizable number of endpoints, right.So we have mappings defined in our gateway.

1:28

So the request flows through our gateway and then gets routed to different micro services.Now for these mappings to happen, we have a yaml file and I've spoken to it at good length and some of these other videos, we haven't seen them.Check them out.The mapping files, the the map, the endpoints are mapped in those the mappings are defined.

1:48

Sorry.The mappings for those endpoints are defined in those YAML files and they serve 2 purposes.The first purpose essentially is the fact that they when your request is, you know is entertained at runtime, it goes through these mapping files.We determine what mappings, where, how the routing should happen and yadda yadda yadda outside of that.

2:06

Those mappings also lend themselves to be published as collections as Postman collections and open API specifications etcetera.So we take those endpoints and publish them on Postman and we start testing the endpoints, right?Let's say we are finding an issue.It could be a code issue or it could be a mapping issue, right?

2:23

In most cases, as it turns out, it's a mapping issue because we have our API endpoints published, you know, and consumed by our own web and mobile app so that they are pretty stable.So it's not really code issues.And even if they are code issues, they're not diagnostic to the existing clients there in the gateway code that we are we are about to go live with, right?

2:42

It's the first version of it.So Long story short, it's either mapping issues or code issues in the gateway.And we we make changes to if it's mapping issues, we make changes to those YAML files and then we republish those endpoints.Now when you republish it, a new Postman specification comes into play.

2:59

We import that specification and then we start testing out.But The thing is, we've iteratively gone through a lot of the directories collections in the previous specification version, right?How how do we tell that those endpoints have already been tested?So we don't have to retest those endpoints unless we actually touch related code.

3:16

We have our own quirky ways of doing it.We have used it in emojis like a smiley, a bug face, an emoji with droplets that tells us that it's in progress, the one of the tick mark that says it's complete or one that says it's failed.We prefix the directories on on Postman with one or more of those emojis, so it gives us an indication of the progression and we also prefix our specific independent individual endpoints with those prefix with those emojis as well, right.

3:47

So it tells us as developers and testers like what's going on, what the progress is because doing this through say GitHub, which is why we do our repo level project management would be very even more laborious because there's a lot lot of endpoints.So we're going to have to track each one of them, add labels to these tickets and whatnot.

4:03

It's going to just slow us down.So we've sort of we came up with this approach that works quite well.We share the workspace with the folks in our team, everyone updates it.So we know what's going on, who's working on what.But the challenge is every time we make changes to the gateway and the mapping files, we publish a new version of this of the Postman workspace.

4:21

And when you import that, there's no way to merge this, right?There's no notion of merging these workspaces unfortunately, unlike code.So it is a new collection that comes into play with a number of directories.Now the tricky part here is how do you port over what has been completed in the previous run to this current run.

4:38

That's where.That's one of the main challenges we've run into.So we've come up with certain design patterns that sort of works for us, but there's no established way.I'm going to share some screenshots about, Hopefully it helps you, gives you a visual representation of what I'm trying to tell you here.So we have, let's say we have a workspace with a number of a collection with a number of different directories and a large number of endpoints in each directory.

5:01

We prefix them like I said earlier, either the the directory itself or the endpoint saying it's done, not done, in progress, failed, etcetera.But when we have a new version, we have to put that over and that's that's a meticulous slash laborious task.So we have not actually done that.

5:18

We have different incremental versions of these Postman workspaces and then if you've completed a directory or an endpoint, we don't put that information over to the next version.It's sort of cumulative.So we have to go back to the previous version to tell that that endpoint has actually been tested.

5:34

It is painful, but it's less painful than creating these tickets and adding labels and statuses and what not, right.So we've been moving along in that fashion.So I'll probably do another video where I have actually speak less to it and show you what actually it looks like and you can tell me whether you've done it differently or what not.

5:52

But this approach works, right?It works and we've been moving along quite nicely.It's just a little, you know, it's a lot of manual intervention here because we haven't got into creating recipes.It's probably once we release the first version, they may be out the door.We're going to then work on creating recipes and business recipes and engineering recipes and whatnot.

6:11

So you as a developer or product owner or product manager can can sort of leverage, consume and understand what value, what business value our endpoints, our APIs bring to the table.So that's all I wanted to share in this we are going through.So ultimately we want to see a workspace.

6:26

We would see a workspace.We expect to see a workspace in our in our postman, in our client that has all directories have a tick mark and all endpoints within each of those directories also have a tick mark.So we know that we've actually tested each and every one of those endpoints and everything works as we expect for them to work.

6:43

So hopefully that gives you some indication.If not, you know, again feel free to hit me up, ask me more than happy to share the experience that we've actually, you know, we have in the process of actually publishing this this first API on our gateway.Thanks for watching.

6:58

Bye, bye.

11. Support for Multiple Environments

There is no natural support for multiple environments on most API Gateways, so you are going to have to be a bit creative and come up with ways that work best for your team(s).

0:01

Hey there, hope you're doing well.Uh, this is UH Podcast #11, I think in this API Gateway series.Uh, uh, in this one I want to talk about UH environments, right?So uh, as we're working through our API Gateway, uh, the first release of our gateway, UH, we've run into a number of challenges and we've waited through, you know, gone past a good number of them and we're at the tail end of, uh, you know, what we're looking at is like maybe a couple of weeks away, hopefully 2-3 weeks from our release date.

0:25

Fingers crossed, again, one of the challenges, I've just documented a ton of what we've run into and this is one more, is the fact that a lot of these API hubs, I say a lot, but probably all of them, I don't believe they support a notion of environments, right.So obviously internally we have dev, test, aging and prod, and you may have fewer or more environments, but these are standard numbers, right?

0:46

So we currently right.So we want to be able to you know we want to be on, we are on dev, the dev, the lowest environment and then we also have local which is completely local to our whole you know sort of a developer sandbox which is doesn't depend on any other environment pretty much for the most part.

1:03

So you could say it's five our machines plus the other four environments, right, so three before we get to prod.But the API hubs doesn't matter what they are like whether it's Blogger or rapid or AWS marketplace if you consider that sort of API hub because it is as well, right.It's a marketplace slightly different, but it falls in that space.

1:21

They I have nothing but just one environment.So there is no, at least from what I've seen.You can go there and create your API and then say I want to actually have four different environments and then make requests have different configuration for each of those environments.It doesn't seem like they any of them support that so it makes it challenging.

1:41

So one of the workarounds, even if it's not it's it's a little bit painful, but it's still viable.Workaround is you create 4 AP is as though they are different, AP is even though they're exactly the same and then call them differently, right?So you have a production version that'll be called, say in our case Nobel Project Management API.

1:58

That's our first API that we're going to publish.And then we have the second one.Imagine 4 cards, the second one would say Nobel Project Management, Dev, Test and staging.The one that's prod doesn't have the suffix prod.The other three do have the environment.Their environment is suffixes, right?So now we can configure each of them specifically and have them pointing to the the corresponding environment of the API gateway.

2:23

And then that environment of the API gateway can then point to a more specific micro service that belongs to that same environment essentially, right?So if you were to draw this out, all of them have to be mapped to the exact same environment.Now you might mix and match some of them because you may not have 4 environments by every single piece in this puzzle.

2:43

But if you don't, then you better have a you know a more manageable strategy because otherwise you're going to get confused.You're going to make a deployment break somebody else's dev or test work or product manager owners cannot be doing what they are supposed to be doing because you you broke something inadvertently and you didn't expect for it to be broken.

3:00

It's it's bound to happen if you have fewer environments or if you kind of mix and match environments.So it's just left to you and how your DevOps works.But the the cleanest way out kind of think of is having one for each and then all the way straight through, right, So one like dev on the hub, dev on the API gateway, dev on our micro services, dev for the databases and so on and so forth.

3:21

It takes a bit of effort and it costs money also right to do have spun all of these environments.So we don't have all of them ironed out and you know laid out that way, but we have a fair bit of what I've just mentioned here.So that's something to keep in mind.

3:36

You know, I hope you know the the hubs actually do support environments that way.You know it doesn't.You don't have to be creative in solving this problem because to me it's it's it's boilerplate stuff if you will, right?I mean you you are building something you want to be able to sort of progress you know through those environments so you need the hub to actually support it.

3:57

So just to recap what we have and we what we're actually starting out to do is trying to have these variations as APIs themselves.And it's not just for the initial release, I can see that just stay there.So the moment we publish a second API, not the second version of the first API, mind you.

4:15

The second API, we're going to have to have four of those cards for those for that API as well.So it's a little bit painful to manage.If we want the day we have like 5 API, we're going to have like 20 cards sitting there even though it's only 5 AP is.I mean five is a lot of AP is, but I see even though it's only because you know it's 20% of the actual number of cards that show up on these hubs, right.

4:36

So that that is, you know, a sizable challenge, something that's eating up our time actually.So I figured I just want to document that and hope it helps you.And again watch out for a release, it's coming very, very soon.We couldn't be more stoked about it.

4:52

It's going to be another feather in our cab.We have the web app and the mobile app, the API gateways, the third in the mix of things, 4th actually, but but third depending on how we look at it.That's about it.Thanks for watching. Bye, bye.

12. Rapid API: VS Code Extension

A quick look at a VS Code extension for Rapid API.

0:00

Hey there, I hope you're doing well in this podcast.Let's take a look at a Rapid API VS Code client.So if you're building APIs and publishing them on API hubs, and let's say in this particular example you're publishing that on a rapid hubbeat, their public hub or their or their enterprise hubs, you might be able to leverage this client.

0:19

So this is my first experience.I just downloaded this like literally like 10 minutes ago and I'm sharing my initial thoughts.So as an example, I'm just going to switch between a couple of screens.So we are working on publishing our API API on the Rapid hub, on a business hub.

0:37

But right now what you're looking at here and the screen here is a public hub.It's a marketplace, so to speak, right?So I'm going to ignore and wait past the items that don't matter with the podcast.Just in the interest of brevity, I'm just going to.My interest here is to run.I've written an API, sorry, an endpoint that does a certain thing, and I want to be able to test it quickly, right?

0:58

As a developer, I'm on VS Code.I used a variety of different editors for different things.VS Code is one of them.I don't exactly use VS Code for API work, but for purposes of this illustration, I think it's fair to assume because it's a beautiful idea as we all know.

1:15

So you could suddenly leverage that.Say I'm using that and I want to be able to test quickly, right?I want to be like hey I've written the code now let me check if my endpoints working well, what do I need to do?First thing I do I would go download the the actual client.

1:30

So if you go you can see that it's got like 140,000 installs.So this is the Rapid API client.You can just install the client, it takes less than a minute to install this client.Or you can go to, you know, VS Code extensions and look for it and once it's installed, you'll see this rapid logo here and you can hit that and it's going to, I guess, it OK And you see that it presents this, right.

1:56

So rather than going to Postman or Insomnia or outside of it, you're able to do this sort of in an integrated manner.At least that's the idea.OK, so I installed the client, and after I did install the client I let's say I go back here, right?

2:13

So if I were to be doing it directly through the browser on one of the Rapid API pages, I could.I could hit test endpoint and you'll see that this returns in a second and it gives me a version number right, 10163.The only thing I needed to put here that mattered was the Rapid API key, right?

2:31

So I've subscribed to it.I went to the marketplace as a consumer of the API, subscribe to it.Now I get an API key and then a rapid API host.Now you can use your custom DNS and do all the fancy stuff which is outside the realm of this.

2:46

This video, this podcast.But this is the URLs.Nopal Project MANAGEMENT api6.p.rapidapisothesubdomainsthep.apirapidapi.com is pretty standard from what I've seen that the first part is what changes based on your company name, your API name, the version number and so on and so forth.

3:06

So I made the request here and you saw that return 10163.Couple of things.Initially when I took this to to VS Code I was hoping that there was a way I would be able to tie in to my to the API so all of these endpoints would actually start showing up here.

3:24

Now I've got to believe that there is a way.There hopefully is a way to make this happen.I don't read documentation very well, I just tried things out.Maybe there's somewhere in here but but skimming through it really quickly I did not see that.So either I'm missing something or that supports not there.

3:42

If it's the former, then it's on me, but if it's a latter, that's a bit of a problem because it doesn't.I can't envision us or anybody adding each and every endpoint 1 by 1 here.I actually had to go in and click click here and after I did, I added a request and I made some changes and added stuff.

4:02

That's a laborious activity and we certainly don't want for it to be done.So there must be a way to either you're importing an open API spec here, or even better, right?Because even if I import an open API spec, that there could be a disconnect between that spec and what's actually hosted on Rapid and that could Causeway the issue.

4:21

So I would imagine that there should be a way to connect to the hub that you actually subscribe to.So you go here and say, hey, connect to this hub, sorry, connect to this API that I subscribe to on the Rapid hub and it should pull up all of those requests and populate everything exactly the way it's done it here.

4:39

Now I would I'll be perplexed with that there is no support for it because that would have been a big mess on the part of Rapid.So I'm going to say that this is something I've just not discovered yet, but I will keep you posted in my subsequent podcast.So short of Maine finding out or it being there, I had to add the request manually.

4:57

And then once I added that I had to add the header and do just about everything manually right.Which Which as I've said before it's painful but that's alright.So I did that and then I made the request.The request looks identical.It's a GET request, goes to this host app, latest version, exact same thing.

5:14

App placed the latest version is the host.I have the rapid API key.I have the rapid API key here, but on actually send it says invalid API key.Oops.You know what?I have a typo here, but I did not have this typo here.Let's see what happens now.Yeah, it's the same thing.

5:29

And then it gives me the 429 too many requests.Not sure what's going on.I'm not sure if I'm doing anything differently.The case sensitive.I don't think these actually are case sensitive.Let's oh they are case sensitive.Never mind.My bad.

5:46

So it actually does work.So that's that's the way you do it now.You know, you would if you're expecting me to stop this recording, go back and do it again and edit this piece out where I made a mistake, then you've not watched my other podcast.I make mistakes all the time and I actually want to be.

6:05

I try to keep these podcasts as honest as possible.So you know, that way it doesn't come across.It's like picture perfect and I'm doing the exact right thing because it's hardly ever the case, right?We all make mistakes and I I think it's important digressing from the original item here and certainly not trying to sound defensive.

6:23

If you watch my net podcast, I would have actually caught myself standing at the wall because I'm not a net developer and I hit a roadblock and I was trying to debug, figure out what to do during the podcast.And I say this here because a lot of times we all worry as as folks who are joining, entering into development or having done this for a while, that we are expected to know everything.

6:43

Not at all right?As long as you're not relying on theory and trying this out.So the thing you ought to do is like 10 minutes after someone sends you a link, respect the time that they took to sharing something with you.If you have the bandwidth doing it right, then check it out.That way if you run into a roadblock or an issue, you could ping them and bug them right back.

7:02

Right?So.So thanks to Scott for forwarding forwarding this link to me.This is pretty cool.This is how you would use it.So the only thing I think I have to figure out is how do you import all of them here and that way you don't exit your IDE.So this is much along the lines of a quick REST utility, nothing fancy in that sense, right?

7:23

And to each their own.I prefer to do these types of things outside of my ID, so I don't know if I would actually end up using this necessarily.I prefer like Insomnia.That's my graph and REST client of choice.And since we are actively working on Postman and publishing those workspaces, I've been using Postman.

7:43

But this looks pretty slick and then you can tell right if you're in your code base.Let's say I go open, I don't know, I just want to pick up random file, let's say open this, generate spec file right?This is script I wrote a few days ago.Now if I don't even have to leave my window right, I don't have to go to Postman or Insomnia, I can come write my code right here, make the request.

8:04

I mean I'm saying the RPS, that's what these plugins are for, but I think it kind of improves your productivity.Now there are some improvements I can see that this can have, but with that said, it does its job.So so far so good.Keep in mind I've run into the fact the headers are case sensitive.

8:22

I want to say let's just check it out.Right Are http://headers case.I want to say the R case.Yeah OK, they are converted to lower case in both directions.So in in that sense, http://header keys are defined to be case insensitive.

8:43

Yeah, that was my feeling as well.So why is this not working?Let's see.Let me change this to high.Oh, it does work now see Rapid API that works as well.

9:08

Oh my God, OK I have no idea.Maybe I have to go back to the top of this video to see because I did think it was not did they were not case sensitive.But I must have done something wrong I thought.I just copied it from here.I just copied that from here and I thought I pasted it here.

9:26

Clearly I must have done something different.So it's all good, It works and it's perfect, right?So you have your header and then all of these things like the description and the query and the body and let's say description.Do I have a description here?

9:43

I do have it as.Oh, of course not.See, this is the problem, right?Because I created this endpoint manually.Never mind, it is not coming from here, so it should actually.There should be a way to point to this.If there isn't, that's a bit of a problem.I don't think importing the open API spec, even if that works, it's not the ideal solution.

9:59

The the client should actually point to, you know, the actual hub itself and pick up the endpoint, the API that you have subscribed to.That's about it.So let's go look at the ratings and stuff.I mean, you have to take gratings with a grain of salt because, you know, folks are generally unhappy about whatever it is that they're unhappy about South.

10:19

I give very little respect to it unless I check it out myself, right?You know, you have to, you know, the devil is in the detail, and it's probably the wrongest ATM to use in this case.I don't know why I said that, because it works most of the time.So probably I just blurted that out.

10:35

Excuse me, but yeah, I don't know if you looked at the first one.It says clunky UI, many bugs, blah blah blah.I mean, I don't see that as a problem.I don't know what's clunky about this UI.It looks like any other UI.It's not particularly unique in any way, but it's it shouldn't have to be because it does what I believe it promises too.

10:56

Let's see some other even more recent downward than marking it's buggy, lacks many features.Yeah, sure, Yeah, I mean, again, right?That's why you need to take the reviews of the grain of salt.I mean, I'm not saying these reviews are right or wrong, but but to me, if it does what I want for it to do to help make me productive, it's good.

11:21

And I think it actually is providing value.If I were to be using Open, I'm sorry VS Code, which I don't for this gateway work.And if I actually rely on plugins as part of the IDs for making these request likes like database plugins and REST plugins.

11:38

I don't right?So I'm not the ideal customer but I actually like it.It looks pretty cool.I mean it looks simple cool.Maybe is the wrong but it looks less like everything else so there shouldn't be an issue.So certainly do check it out, 40,000 other people have done it, so why not, right?

11:55

That's about it in this podcast and hopefully this helped you a bit.Thanks.

(Snowpal) Backend as a Service APIs, Apps, Courses, Podcasts

Discussion about this post

(Snowpal) Backend as a Service APIs, Apps, Courses, Podcasts

API Gateway Series: Publishing Snowpal API (from start to finish)

AWS API Gateway. Snowpal APIs.

Table of Contents

1. Introduction

2. Postman Workspace & Readme Documentation

3. Gateway Deployment & Topology

4. Backward Compatibility of APIs

5. API Monetization

6. API Hubs

7. API Documentation

8. API Gateway

9. OpenAPI & Readme

10. Testing API Endpoints

11. Support for Multiple Environments

12. Rapid API: VS Code Extension

Snowpal Products

Discussion about this post