Generative AI went viral in the last year, many use cases show the ability of generative AI, such as text, image, video, music generation, and more. It helps people to create more content with less effort. However, unlike conventional APIs, the Gen-AI API often has a relatively longer latency and higher costs due to the need for better (more expensive) GPU resources to enhance performance.
Idempotency API means that the data / system state will be the same no matter how many times the API is successfully called with the same request body/parameter.
We've described why we need and how to design an idempotency API mechanism in the article How to design an efficient Idempotency API, If you haven't read it before, please refer to it.
This article will focus on implementing it in an existing project, which is my event-sourcing POC project. Here are the implementing steps:
Large-scale Change (LSC) within software development often presents massive challenges. It's a scenario that needs careful planning to meet the need for stability. As DevOps philosophy evolves at a rapid pace, seamless implementation, testing, and release of these changes becomes necessary. This is why feature toggles emerge as a valuable tool, offering a variety of strategies to manage, test, and deploy large-scale changes effectively.
In this article, we will mainly describe how to develop, test, and release an LSC safely with feature toggles. Starting from the definition of LSC, why it needs help from feature toggle, and what kind of LSC can be covered. Next, we will introduce what kind of toggle we will use, and brief the migration schedule. Finally, we will show what to do with the code and toggle settings during the development, testing, and release stages with an easy demo. Let's begin!
Idempotency API means that the data/ system state will be the same no matter how many times the API is successfully called with the same request body/parameter.
For a well-follow-principles RESTful API, besides the POST and PATCH, all other methods are idempotent. But in some particular circumstances (e.g. create a payment, upload files, microservice communication...), it is essential to implement idempotent if we want to make an API more robust.
In This article, we will propose an idempotency mechanism that is also focus on the API performance. The topics we will cover are as follows:
As we mentioned in this article before, centralizing all the needed knowledge in one developer portal is a big improvement in daily working experience and convenience.
But we face a CORS problem when sending requests by an embedded swagger page in the API definition. this problem will significantly reduce the functionality of the Swagger page, so this article proposes three ways to solve it: