Hi guys, Please set the speed to 0.75x if you feel it's fast. I realized later in the next day when I watched 🥲 Thanks to "@Think_First12" for bringing this up as an end user 🙌
The example we have shared in context of movies application, where primary entities are movies. As the relation between movies and actors can be many-to-many, we can also have something like this “…/api/v1/actors/:actorId/movies”
good job brother, nicely explained. Some concpets like cursor, I have seen in open source projects but wasn't aware about the reason bheind the implementation.
Good question! Simplifying API naming conventions boosts consistency and developer productivity, but security wouldn't be compromised. Security is a separate layer that must be strictly enforced like authentication, authorization, rate limiting, and data validation are crucial to protect APIs from risks - irrespective of how simple or complex the naming conventions are. In summary, even with self-explanatory naming conventions I don't see of a case where it exposes any security risks. If you can share an example, I can definitely explain in accordance with it. Thanks for dropping a comment - appreciate the thoughtful question! 😊
I have one question. It is related to Database side. Suppose we are retrieving all the records from a particular table and suppose we are using a ORM, and we also need to send total records count with the original records as well in the API response then we should have two DB queries? One to retrieve all the records and another to retrieve total count of that table? What should be done in this case ?
Good question! In short: yes, 2 separate db queries ( 2 IOPs ) Assuming lets say, the use case is to display on frontend, - we can use 2 separate API requests one for count and other one to get only a set of records with pagination concept (or) - the same listing API can have both count and set of records, however if table records length is not changing in seconds or minutes - with pagination we will end up querying count db call unnecessarily. Hope this explains 😊
Good point, usually once an api end point is production ready, as per the semantic versioning lets say the frequency of major version change would happen once in 5 years as an example and this interval purely depends on the application growth, volume and re-architecture requirements. If an end point in a very short span keep changing then either its not production ready in the first place and we can stick same version until it goes live or bad design in the first place 😉
Content is awesome but I have a basic issue that is your voice speed. To listen you probably I had to set video speed at 0.75X. so if you had uploaded the video at 1.5 or 2X speed then please don't do that.
Thank you for the feedback, yes I did at 1.5x 🥲 My bad, realized next day when I watched with fresh context. Now it’s confirmed with your feedback that it’s speed overly adjusted, noted and will be improved from now on 🙌🏻
Hi guys,
Please set the speed to 0.75x if you feel it's fast.
I realized later in the next day when I watched 🥲
Thanks to "@Think_First12" for bringing this up as an end user 🙌
Awesome bro
Thanks for teaching us about what actually happens in industry..
The way you explained made it so much easier to understand!
Thank you 😊
Informative. Good effort and content.
Thank you 🤩
I didn’t make it 1.5x myself😅 Thanks for such content.
Keep it up bro.
Great
Thank you 🙌🏻
at 12:24 , it is also possible that one actor has many movies . why we are considering the only case that one movie can have many actors
The example we have shared in context of movies application, where primary entities are movies.
As the relation between movies and actors can be many-to-many, we can also have something like this
“…/api/v1/actors/:actorId/movies”
good job brother, nicely explained. Some concpets like cursor, I have seen in open source projects but wasn't aware about the reason bheind the implementation.
@@Petrichor1314 thank you 🙌🏻
If we make api conventions too easy then won’t it expose the api to locate address and security risk?
Good question!
Simplifying API naming conventions boosts consistency and developer productivity, but security wouldn't be compromised.
Security is a separate layer that must be strictly enforced like authentication, authorization, rate limiting, and data validation are crucial to protect APIs from risks - irrespective of how simple or complex the naming conventions are.
In summary, even with self-explanatory naming conventions I don't see of a case where it exposes any security risks.
If you can share an example, I can definitely explain in accordance with it.
Thanks for dropping a comment - appreciate the thoughtful question! 😊
I have one question. It is related to Database side.
Suppose we are retrieving all the records from a particular table and suppose we are using a ORM, and we also need to send total records count with the original records as well in the API response then we should have two DB queries?
One to retrieve all the records and
another to retrieve total count of that table?
What should be done in this case ?
Good question!
In short: yes, 2 separate db queries ( 2 IOPs )
Assuming lets say, the use case is to display on frontend,
- we can use 2 separate API requests one for count and other one to get only a set of records with pagination concept (or)
- the same listing API can have both count and set of records, however if table records length is not changing in seconds or minutes - with pagination we will end up querying count db call unnecessarily.
Hope this explains 😊
@@SWE-with-VivekBharatha Thanks!
10:41 Who is that guy sending api key in query params 😂. Nice video btw
@@hruthikks1610 Thank you! 😊
You would be surprised if you search like this in google: ‘"API_KEY" "query parameter" documentation’ 😅
If we do versioning like v1,v2 etc would it go out of hands after some time? How to solve for that problem?
Good point, usually once an api end point is production ready, as per the semantic versioning lets say the frequency of major version change would happen once in 5 years as an example and this interval purely depends on the application growth, volume and re-architecture requirements.
If an end point in a very short span keep changing then either its not production ready in the first place and we can stick same version until it goes live or bad design in the first place 😉
Content is awesome but I have a basic issue that is your voice speed.
To listen you probably I had to set video speed at 0.75X. so if you had uploaded the video at 1.5 or 2X speed then please don't do that.
Thank you for the feedback, yes I did at 1.5x 🥲
My bad, realized next day when I watched with fresh context.
Now it’s confirmed with your feedback that it’s speed overly adjusted, noted and will be improved from now on 🙌🏻