sergk / fastapi Goto Github PK

Description

As a user of the FastAPI application, I would like to have the ability to trigger background tasks via a new API endpoint /process. This endpoint should execute a simple background task, such as running a command to sleep for a specified duration, and return the ID of the started task. Additionally, users should be able to check the status of background tasks using a polling approach by implementing a new endpoint /getresult which retrieves the task status by ID.

Requirements

• Create a new API endpoint /process to trigger background tasks.
• When accessed, the /process endpoint should initiate a background task.
• The background task should involve executing a command to sleep for a specified duration, e.g., sleep 15.
• Upon successful initiation of the background task, the endpoint should return the ID of the started task.
• Implement a new API endpoint /getresult to retrieve the status of a background task by its ID.
• Users should be able to poll the /getresult endpoint to check the status of a background task.

Additional Notes

• Ensure proper error handling and informative responses for both endpoints.
• Consider implementing task management features such as cancellation or status updates.
• Maintain consistency with existing API design and adhere to best practices for RESTful APIs.
• Documentation updates may be required to reflect the new endpoints and their usage.

Acceptance Criteria

• The /process endpoint successfully triggers a background task and returns the ID of the started task.
• The background task executes the specified command, e.g., sleep 15.
• The /getresult endpoint retrieves the status of a background task by its ID.
• Users can effectively utilize polling to check the status of background tasks.

References

• FastAPI Documentation
• Background Tasks in FastAPI
• Polling in Web Development

Priority

Medium

Labels

• enhancement
• API
• background-task

Add the necessary code and functionality to implement CRUD (Create, Read, Update, Delete) API endpoints for managing a user database in the FastAPI application. The user database will be an in-memory database that stores users' data: username, email, and number of tasks. Additional checks and validations should be implemented as specified below.

Requirements:

• Users should be represented using a Python class or data model that includes the following fields:

  • Username (string)
  • Email (string, validated as a proper email format)
  • Number of tasks (integer, validated to ensure it's not a negative number)

• The API should support the following endpoints:

  • GET /users/{user_id}: Retrieve a specific user by their ID.
  • POST /users: Create a new user.
  • PUT /users/{user_id}: Update an existing user by their ID.
  • DELETE /users/{user_id}: Delete a user by their ID.

• The API endpoints should interact with an in-memory database that holds the list of users.

• Proper error handling should be implemented for cases such as invalid user IDs, non-existent users, incorrect email formats, or negative numbers of tasks.

• The code should be well-structured, readable, and follow best practices for FastAPI development.

Additional Information:

• The baseline FastAPI application is provided in the app/main.py file.
• Make sure that the code is covered with unit tests.
• Run the code and test the API endpoints to validate the functionality.

Acceptance Criteria:

• The FastAPI application should include the implemented CRUD API endpoints for managing the user database.
• The endpoints should have the necessary checks and validations in place.
• The application should utilize an in-memory database to store and retrieve user data.
• Error handling should be implemented for invalid requests or scenarios.
• The code should be well-structured and follow best practices.