Building Powerful APIs with Django, Django Rest Framework, and OpenAPI with Velda Kiara

This is amazing. I'm grateful to be here first of all. But then apologies. I'm going to have to rush through a couple of things. But don't worry, you'll have good content to go home with. So there is that. So when I was younger, say six, seven years old, we used to get the Super Strikers magazine, which is which is about having football players just play football and then they have other teams that they need to also come up against and then they'll face a couple of challenges and then at some point then they'll either win, they'd either lose, and then learn a couple of lessons So this is actually the first comic book I came across. And it used to come on the weekend newspaper. So every single week on the weekend, this is what I used to look forward to.

So in this particular scenario, I didn't get the issue for this for that particular weekend, which was Obama because We were left at a cliffhanger. We didn't know if the person had scored the goal or not, what was going on. So I was really excited for this particular issue. But then when the newspaper was delivered to us it it it was missing the issue. So I told my parents this. I was like, okay, you know, this my routine is normally involved with reading the Super Strikers every morning and then telling my brothers about fake stories. So every time they're reading it, they're looking at the scenario I told them about, but then they can't find it. So that's how I got to also improve my storytelling skills. Don't tell them that though. And every time this particular weekend they were like, okay, we'll find or get you one

at the end of the day. I'm like seven years old. At the end of the day is like a decade to me. Like my time is different, right? So I devised a plan to actually leave the house and go to the distribution center was like which was like two, three minutes away, so I could easily walk. And I walked, I I rehearsed w what I was supposed to say and tried to act like an adult at that time and ask For the magazine that was owed to me at that point. And the person at the reception desk was actually really nice. And she was like, oh yeah, there's an issue that was missing, but then we were supposed to deliver it to you. At the end of the day, I'm like My time doesn't work like that. So I just need to pick up my issue right now. So the person was nice to me and they actually gave me the issue and I went back to my routine to telling my brothers about the fake stories and all that.

So That went well. So in this case, when I'm talking about APIs, the request I raised to the reception lady is actually the request that as a user or as a client in this case raises to APIs. And the response of her checking the back and seeing if there's actually an issue and checking if I should actually get the issue is a response from the particular server. So that's basically how APIs work. You raise a request and get a response. So yes, I needed answers. I could not wait the whole freaking day. So there is also that And moving on to status codes. So generally when you raise a request, the response you're supposed to get is in

form of status codes. So there's the five general classes that you should get responses in. And the first digits signifies the general class and the last two digits are specific information about that particular bug. So if you're getting an error code or a status code of one, that means, okay, we got your request, we're working on it. If you get two, that means like 201 or 200, that means we've gotten your request, and here's the result But if you're getting three, that means a nobody got time for that. We're not going to do that today, but we can send you to a place where you can get your requests. fulfilled and if you're getting four as a server my response to you is like nah you did something wrong it's your fault check the syntax that you're using

And if you're getting five, then that means, okay, my bad, it's me, it's not you. If you know, you know So if you're looking at also whenever you're trying to build your APIs, we tend to still build out and design their particular specification and then build that out before even building the front-end interface in other components. So the first reason why it's recommended to actually design and define your API first is because you get to separate your concerns. So you get to separate the back-end logic and the front-end implementation so you can easily develop the decoupled components, right? And it's easier to maintain and update And then you also get flexibility and scalability

because you're able to have different teams working at different times. And then you're also able to get all the information that you need to accommodate both users, that is the existing users and the new clients you're going to have. It also improves in terms of collaboration and parallel development because the teams can work side by side without having the dependencies and then thinking about what the API is going to be or what the results and responses are going to be allows you to have a clear and concise interface because now you've thought about the response. and the various uh formats and error messages that the user is supposed to get. If you're starting with the API first, it's also easier to Uh get your documentation, you can easily automate this, and then you can easily add a few concepts that you want the user to know.

So it makes work easier for your documentation. And also in terms of feature proving, that means that you're able to account for To have a stable version. So regardless of whether the front-end changes or you're using a different back end or there's a recent development, you can still be able to use the API regardless of that And another thing is that you're also able to have other people join in. You could have other people also support and use your particular API to build other services so they to increase the user base that you have. So it's a win-win for everybody. And if you're working with APIs, the five common request methods that are, these are not the complete requests, there's also one I came across

Called pass. I haven't used it yet, but this is basically the common things that you should accept. Like the get method. So the get request method is where you the request basically retrieves the data that's already existing in the server and the without making any adjustments to it. So for post is where you actually add a resource to the server and for put and patch, which is interviewer's favorite question, what the differences are between put and patch. So if you're using the put request then you're changing the resource in its entirety That is your if the resource has like ID, price, description, and all that, you get to change all of it. But if you're just patching, then you're just updating partial information to that And deleting is where you get rid of the entire resource.

And then in this case, we're going to be talking about uh REST APIs, which means is representational uh state transfer, yeah, which means that REST APIs, the state is actually included in the request, so the server doesn't really need to store anything as pertains to that request. And then when it comes to the Open API specification, so it's a list of what needs to happen at what time Like what is the resource? What is the endpoint going to look like? What's the format of the responses you're supposed to get? What is the data schema you're using? What are the data objects involved? And what not So moving on, why I chose to use URF. I'm going to explain like five of this because of

time, but I chose URF because of one, there is a lot of support community-wise, you can easily get on. and learn because there are so many forums, there's so many tutorials out there, and it's also built for Django, so it's just makes it the easier choice. Also it handles serialization, which means that rendering and passing your data is quite easy. And then in regards to pagination and filtering, it also helps it comes with this like out of the box. So you just be to specify the amount of fields or the amount of data the particular user is supposed to get. And there's also a lot of that party usage and it also covers security. So in terms of views, there are different methods. You could implement

views you could easily use Generics or resets. This is highly determined by the decision that your team needs to make, or rather the project specifications and also the needs of the team as well. So for me, I'd go with generics if I have a simple application I want to build and if the operations are really easy to also implement. It also uses the standard conventions and you have less code because most of the time a one-liner can handle let's say retrieve, update and destroy data with just one line And then it also runs on the default behavior of how APIs should work. So it still works. Now, if you want more control, or if the application you're working on actually needs more logic implemented.

based on your business needs, then I would recommend view sets because you get to customize the logic that you have. You get to have the control in terms of who has access to what and you can easily group this in roles And then there's also reasonable reasonable code as well. And you're also able to manage complex relationships in regards to whether you're having a lot of interconnections in regards to also authentication, what are you using for authentication? How are you going to group these people in particular groups. And before I go into caching, so I have code that I was supposed to demo here. Just a second. So it actually works. So the endpoint I built was on treasures.

Okay. Yeah, it works. This is what we were trying to achieve. So it actually works. Um, I didn't do I swear it works. I actually have rest Tests here, so you could easily test it out. It's also a Docker image, and I'll share the repo in just a second. So for treasures, say we want to create one, a resource. So we have name prize. and description. So let's say uh Drew's sweater and let's price it to say Five dollars and sixty-six cents. And then description is yellow squatter Yeah, then post this and see if it actually, yes, it works.

So when you go to the treasures list You can actually see Drew's sweater has been updated. So the endpoints actually work. You can create, you can see the list view and whatnot. And something else about the code, it's also a Docker container so you can easily run it and you can give me feedback or if you also have any questions about it, then we could get into that So caching is storing frequently accessed data in a temporary location. Which means you don't need necessarily need to send requests every single time to your server. And that means that your users get to get the data as fast as possible.

So first things when you're implementing caching, you need to know data volatility. So how frequent does your data change? Is it like stock prices which is highly volatile and highly changes? And how do you even get to manage your, how's the traffic? Can your API manage a lot of traffic at peak times? How does it handle all the requests that come in. And also in regards to response time, how fast do you want your right your responses to get to your users? Is it instantaneous? Does it lag for a minute And then also API resources are finite, so it's a little bit you need to be able to extend these resources to fit the particular users that you have something that I'd like to talk about is then if you're caching then the next question is

how do you actually maintain the freshness of your data So to maintain the freshness of your data, you need to have things like cash expiration dates. This is where you actually set timelines based on the data. As I mentioned, if you're having like stock price kind of data, then you need to know like at a certain time, like say every five minutes. then refresh this data. And in terms of validation, there are three methods that you could actually do cache invalidation, which means mechanisms that remove or update their entries once the data changes. So one is time-based, which is basically like cash expiration. And then there is event driven for people who love event-driven architecture. That is where you set triggers to notify the cache system when data changes occur

and then manual invalidation where you can have an interface to actually have a person do it for you We also have lazy loading or cache assigned pattern where the cache is only updated when the data is requested. So when the data is requested, it first gets to the cache and then the cache sends the data to the user. And then you could also version your particular API endpoints where if the cache the the server compares the data that it has. to the data that is cached. So if the cache data is uh older than the server data, then it updates the cache. And then You could also have cache control headers where you leverage cachet control methods or headers like cachet control

max age or no cache to instruct the caching proxies and clients on on how to cache or revalidate the data. We also have conditional requests, which means implementing mechanisms like e-tags and last modified headers. So clients can include these particular headers in their requests and the server can respond with either a 304, which is an upmodified status code, if the data is not modified. And then you could also have background updates for those who have also Chrome jobs. So you could easily have set up jobs to actually refresh and update data that necessarily doesn't change every single time And then if you're using real-time data, you could have WebSockets or server send events to push updates to clients immediately by bypassing the cachet

every time it's necessary. And then you could also monitor and measure that by implementing a latte and systems to track the health and the freshness of the Your particular data. The last thing, I hope I'm still on time, is the benefits of caching. So when you implement caching, there are a few things that you are actually Having you're getting improved performance because then the users are getting the data instantaneously. So it's not somebody who's like waiting for the data because as a user Every time you click okay, you want it to be like, okay, you're done. You can go to the next thing. Because other if it takes a lot more seconds, you're complaining that it has a performance issue, right?

So you also get reduced latency because then the user is can easily get the data instantaneously and then you also get the lower server load because the server is not being engaged at every single request. And then you also have enhanced scalability because once the users that have already requested the data and the data is at the cache, then you can serve new users who are using your particularly API. So I had something on implementation. So you could either do in memory caching Or database caching. So in memory caching basically means that you store data in the server's ROM for fast retrieval. So this is how you implement this. Don't worry, I'll share the slides

You could use something like Django Redis for this. The code is updated with a file, so don't worry about that. And then we have database caching Which is basically database caching is storing frequently accessed data in the database itself for quick retrieval. And then that's how you implement that. And then we have CDN caching if you're using a CDN, which is Storing the static assets and content on distributed servers for global delivery. So the last thing I'd want to look at is in terms of security. We have Four factors, which means

that we can look into authentication, authorization, and data protection as well as API keys. So I think you've all heard of the term when people are uh celebrating each other and they're like okay uh say abby is exactly who she says she is like because they've done like a bit of boss moves or something So that is basically what authentication is. It's actually proving who you say you are. And a few things that you could look into is on user authentication, like using tokens, you could have API keys or 2FA, which we all use. Every time somebody else logs in into your uh Google account, you always get is it you? Is are you sure? Is it you So yeah, that's pretty much it. And then on authorization, it's more or less what actions can you take based on

who you are. Like what are you allowed to do in the system? So the next thing is on data protection in itself. You could easily do this through encryption such as Using AES, which is our symmetric block cipher, which means that the same key, the sender and the receiver have the same key to encrypt or and decrypt the data. And then data masking is what happens when you're feeding your credit card information to the particular system they're using. Because you don't want anybody to just have this particular data. And then there's also the actual validation, which is validating and sanitizing the user input to prevent injection attack. We have lastly

API keys, which is basically you can do this through key management by rotating the keys that are there. You could have usage limits if you have rate limiting on your API, which is highly advised so that you don't have your resources disrupted or destroyed. And then you could also have scope-based keys, which means if you have particular keys, then you have access to more functionality. So I tried my best. Any questions so far? Okay, there are no questions. I could, this is a QR code that has the GitHub repo, it has the slides with more information, it also has access to the code base in itself. And then I have been wanting to come here for the longest time.

It only took me three years to actually attend this conference. I knew about it in 2020. So this is a huge moment to me or for me in this case, regardless of whatever took place. I enjoyed coming to this conference. I have enjoyed talking to you. Hopefully if there are any questions that come up I'm still around the conference, so you could easily talk about that. And yes, thank you so much. And I hope you enjoy the rest of the conference.