Future Direction of LightAPI – Sharing My Vision and Seeking Your Feedback

[iklobato]

Hi everyone,

I hope this message finds you well!

I’ve been working on what I believe is the future of LightAPI, and I’d like to share my vision with you. The latest code reflects how I imagine LightAPI evolving, and I’m excited to hear your thoughts on it.

Keep in mind that the core idea behind LightAPI is to enable the creation of a single class that natively handles all RESTful behaviors and HTTP methods.

Below is a brief overview of the core changes and improvements that I think will take LightAPI to the next level:

1. GraphQL Integration

   • I believe that implementing native GraphQL support through the new GraphQLEndpoint class will enable us to build APIs that are more customizable and dynamic. Clients will be able to query exactly what they need, and I see GraphQL playing a key role in making LightAPI more flexible and scalable as we move forward.

2. Asynchronous Programming

   • I see async/await support as a crucial enhancement to improve performance, especially for I/O-bound operations. This will allow us to handle real-time requests more efficiently and position LightAPI to scale more effectively.

3. Background Task Execution

   • I believe that adding background task execution using the BackgroundTask class will make the framework more robust. This will enable long-running processes, like sending notifications or processing large datasets, to be handled in the background without blocking the main thread.

4. File Upload Handling

   • I think having a built-in decorator for file uploads will greatly simplify how we manage file operations. It streamlines the process for any endpoints that need to handle file uploads, making the development experience smoother.

5. Authentication Enhancements

   • Supporting both OAuth and JWT authentication provides greater flexibility and adaptability for various use cases. I believe this will strengthen the security foundation and help LightAPI serve a broader range of applications.

6. Advanced Caching and Pagination

   • I believe that introducing customizable caching with Redis and more flexible pagination strategies will improve performance when handling large datasets. Caching GET requests where appropriate will also help optimize resource usage.

7. Middleware for Security and Flexibility

   • I see the enhancements to the middleware layer, particularly CORS handling and custom authorization middleware, as key improvements for ensuring compliance with modern security standards and preparing the framework for more complex use cases.

To achieve these goals, I've outlined an action plan focusing on the technical development tasks required:

Action Plan

1. GraphQL Integration

• Determine the best approach for integrating GraphQL into LightAPI.
• Develop the GraphQLEndpoint class to support dynamic and customizable queries.
• Create common GraphQL use cases within the implementation (e.g., querying specific fields, handling mutations).
• Integrate GraphQL schemas and resolvers for data models.

2. Asynchronous Programming

• Update all core LightAPI features to support asynchronous operations using async/await.
• Refactor existing endpoints to utilize asynchronous handling for I/O-bound tasks (e.g., database queries, external API calls).
• Optimize the framework to leverage asynchronous operations for improved performance.

3. Background Task Execution

• Develop the BackgroundTask class to manage deferred operations (e.g., sending emails, processing data).
• Integrate a task queue system (e.g., Celery with Redis broker) for efficient background processing.
• Incorporate background task functionality into relevant endpoints where non-blocking operations are beneficial.

4. File Upload Handling

• Finalize the file upload decorator @file_upload to simplify file handling in endpoints.
• Implement file upload functionality supporting various file types and sizes.
• Implement security measures for file uploads (e.g., file size limits, validation of file types).

5. Authentication Enhancements

• Integrate OAuth authentication alongside existing JWT authentication.
• Add support for multiple OAuth flows (e.g., Authorization Code, Client Credentials).
• Configure authentication classes to be adaptable for different endpoints and use cases.
• Enhance security practices within the authentication mechanisms to ensure robustness.

6. Advanced Caching and Pagination

• Integrate Redis caching for GET requests to improve performance across endpoints.
• Develop the CustomPaginator class to handle pagination of large datasets efficiently.
• Optimize caching strategies, including cache invalidation protocols to prevent stale data.
• Implement flexible pagination options such as limit, offset, and sorting capabilities.

7. Middleware Enhancements

• Enhance the middleware layer with comprehensive CORS handling.
• Implement custom authorization middleware to manage access control.
• Ensure middleware components can securely handle cross-origin requests.
• Configure middleware to be easily customizable and integrable with various API use cases.

This action plan focuses on the technical development tasks necessary to achieve the envisioned features for LightAPI. By systematically addressing each item, we can work towards enhancing the framework's capabilities and aligning it with our future goals.

I’d love to get your feedback on these changes and the action plan. In particular, I’m curious to know what you think about GraphQL and whether you believe it's the right approach for making LightAPI more dynamic and customizable.

Your thoughts and opinions will help shape the future of LightAPI, so please feel free to share your suggestions or concerns.

Looking forward to hearing from you!

Best regards,
Henry

[iklobato]

@LexLuthorAJ @giulio333 @MyGodItsFull0fStars

[giulio333]

The ideas you have proposed, such as the integration of GraphQL and support for asynchronous operations, are certainly exciting and will undoubtedly take LightAPI to the next level.

However, given the complexity and number of tasks to tackle, I believe it would be useful to create some project documentation before starting the development. This could include UML diagrams to better define the interactions between components (e.g., endpoints, authentication, middleware, etc.) and a clear plan outlining the dependencies between the various tasks.

We could create these documents directly in the public documentation, under a dedicated section, to encourage collaboration and ensure that everyone is aligned on the design and technical direction.

What do you think?

Best regards.

[iklobato]

You are totally right Im going to finish this native jwt feature (already have a PR for that) and then my priority will be documenting. Once we have everything ready we can move to the next level

…

On 20 Sep 2024, at 15:03, giulio333 ***@***.***> wrote: The ideas you have proposed, such as the integration of GraphQL and support for asynchronous operations, are certainly exciting and will undoubtedly take LightAPI to the next level. However, given the complexity and number of tasks to tackle, I believe it would be useful to create some project documentation before starting the development. This could include UML diagrams to better define the interactions between components (e.g., endpoints, authentication, middleware, etc.) and a clear plan outlining the dependencies between the various tasks. We could create these documents directly in the public documentation, under a dedicated section, to encourage collaboration and ensure that everyone is aligned on the design and technical direction. What do you think? Best regards. — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEKLDKIH73W6QUAJ2QHNJL3ZXRPPHAVCNFSM6AAAAABOQXJ7SKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRUGI2TKOJXGE>. You are receiving this because you authored the thread.

[CatChenal]

Action plan 2: perhaps implement via HTMX? See blog:
https://www.speakeasy.com/post/python-http-clients-requests-vs-httpx-vs-aiohttp

[iklobato]

Action plan 2: perhaps implement via HTMX? See blog: https://www.speakeasy.com/post/python-http-clients-requests-vs-httpx-vs-aiohttp

httpx will be awesome, specially when using pythons context manager