daniel-boll / axum-js

A Axum http wrapper for NodeJS

Daniel Boll

axum-js's Issues

Implement Additional HTTP Methods in `axum-js`

To make axum-js a more comprehensive and versatile API framework, it's essential to extend support to all standard HTTP methods. As of now, only the get method is implemented. This task involves adding the remaining standard HTTP methods: post, put, delete, options, head, patch, trace, and connect.

Each method should accept a path (as a string) and a callback function, similar to the existing get method. This enhancement should follow the pattern established in Issue #3 (Extend get Method to Support Callbacks).

Example for the post method:

app.post('/', (req, res) => {
  res.send('Post request received!')
});

Acceptance Criteria:

• Implement the post, put, delete, options, head, patch, trace, and connect methods, adhering to the callback support pattern established in Issue #3.
• Ensure each method accepts a path string and a callback function as arguments.
• Update the type definitions, documentation, and tests to reflect these new methods.
• The implementation should adhere to the project’s STYLE_GUIDE.md and be consistent with existing code patterns.
• Create a PR with the necessary code changes, updated documentation, and tests.

Dependencies:

• Depends on the completion of Issue #3 (Extend get Method to Support Callbacks).

Additional Context:

Implementing these additional HTTP methods will significantly enhance the versatility and utility of axum-js, aligning it with other full-featured server frameworks.

Implement Simple API Example

The README includes a simplified example of how to use axum-js to create a basic API. The task is to ensure that the provided example is functional and accurately represents the usage of axum-js. The implementation should follow the guidelines and structure as depicted in the README:

import { axum } from "@lambda-group/axum-js";

const app = axum();
const port = 3000;

app.get('/', (req, res) => {
  res.send('Hello World!')
});

app.listen(port, () => {
  console.log(`Server is humming on port ${port}`)
});

Acceptance Criteria:

• The example code from the README is implemented and verified to be functional.
• Any necessary corrections or adjustments to the README example are documented and a PR is made to update the README, if necessary.
• Ensure the implementation adheres to the project's style guidelines as outlined in STYLE_GUIDE.md.

Create Tests for HTTP Methods in `axum-js`

To ensure the reliability and correctness of the HTTP methods implemented in axum-js, comprehensive tests need to be written. These tests should cover all the HTTP methods (get, post, put, delete, options, head, patch, trace, connect) and verify their functionality as expected.

Each test should check the following:

• Correctness of the method operation.
• Proper execution of the callback function.
• Correct handling of different types of input (e.g., varying paths, valid/invalid callbacks).

Acceptance Criteria:

• Create a test suite/file dedicated to testing the HTTP methods.
• Write individual tests for each HTTP method ensuring they function as expected.
• Ensure that tests cover a variety of cases including edge cases and invalid input scenarios.
• All tests should pass successfully with the implemented HTTP methods.
• Create a PR with the new tests, and ensure it adheres to the project’s STYLE_GUIDE.md.

Dependencies:

• Depends on the completion of the issues related to implementing HTTP methods and extending the get method to support callbacks Issues #3 and #4.

Dependent on: #3, #4

Additional Context:

Having a robust set of tests is crucial for ensuring the reliability of axum-js, particularly as more features are added and the codebase grows.

Error to build on mac m1

Hey i try to compile axum-js on mac m1, but i have some problems and my skills with Rust is limited, do you know something about this?

Os:
MacOSX 13.0

Chipset:
Apple M1

Rust Version:
1.75.0

PS: I know the M1 is not supported, but is there anything I can do?

Create and Host Project Documentation using Docusaurus, Vercel, and Free Domain Registration

The aim is to create comprehensive documentation for axum-js to aid developers in understanding, using, and contributing to the project. The documentation should be created using Docusaurus, hosted on Vercel, and accessible via a custom domain registered through Free Domain Registration with a *.is-an.app domain.

The documentation should be structured and include the following sections:

• Getting Started
• API Reference
• Usage Examples
• Contributing Guide
• FAQ

Steps:

1. Set up Docusaurus within a docs/ directory in the project.
2. Create content for the outlined sections.
3. Set up the project on Vercel for continuous deployment.
4. Register a *.is-an.app domain and configure it to point to the Vercel deployment.

Acceptance Criteria:

• Documentation is well-structured, informative, and covers the outlined sections.
• Docusaurus setup is correctly configured and styled.
• Vercel deployment is successful and continuous deployment is set up.
• Custom domain is registered, configured, and points to the Vercel deployment.
• Update README to include a link to the documentation website.
• Create a PR with the Docusaurus setup, content, and updated README.

Additional Context:

Creating thorough documentation is a crucial step for the growth and adoption of axum-js. Hosting this documentation on a dedicated, easily accessible site will provide a better user experience for developers.

Extend get Method to Support Callbacks

The current implementation of the get method in axum-js only accepts a string argument for specifying the path. To enhance its functionality and align with common JavaScript/TypeScript practices, it is essential to extend the get method to also accept a callback function. This callback function should be executed when the route is accessed.

Currently:

app.get('/', (req, res) => {
  res.send('Hello World!')
});

The callback function provides a mechanism to handle requests and send responses, enabling more dynamic and interactive API endpoints.

Acceptance Criteria:

• Update the get method to accept a callback function as an argument alongside the path string.
• Ensure the callback function is executed when the specified route is accessed.
• Update any relevant documentation, type definitions, and tests to reflect this change.
• Ensure the implementation adheres to the project's STYLE_GUIDE.md and is consistent with existing code patterns.
• Create a PR with the necessary code changes, updated documentation, and tests.

Additional Context:

Supporting callbacks is a step towards making axum-js more flexible and user-friendly, aligning with common patterns used in JavaScript and TypeScript-based server frameworks.

Implement Optional Default Logging in Rust Modules

To enhance debugging and observability, it's proposed to add optional default logging within the Rust modules of axum-js. This logging should cover key events such as server startup, routes registration, and any other significant lifecycle events. The logging should be designed to be toggled on or off via a JavaScript API to avoid unnecessary log verbosity in production environments.

A proposed API in JavaScript to enable logging might look like this:

import { AxumApp } from "./index";

const app = new AxumApp();

app.registerLogging({ emoji: true, timestamp: true });

In this example:

• emoji: true would enable emoji icons in log messages for better readability and quicker identification of log levels or events.
• timestamp: true would prepend timestamps to log messages to provide context on when events occurred.

Potential log messages include:

• "🚀 Server started at port {port}"
• "🔗 Route registered: {method} {path}"
• ...and others as deemed necessary.

Acceptance Criteria:

• Implement a logging mechanism within the Rust modules that can be enabled or disabled through the JavaScript API.
• Ensure the logging API in JavaScript is easy to use and well-documented.
• Log key events such as server startup and route registration.
• Ensure that log messages are clear, informative, and follow a consistent format.
• Update documentation to explain how to enable/disable logging, what events are logged, and how to use the JavaScript API to control logging.
• Create a PR with the implemented logging mechanism, updated documentation, and necessary tests (if applicable).
• The implementation should adhere to the project’s STYLE_GUIDE.md.

Incorporate Socialify Banner, Deployment/Test Badges, and Sponsorship Section

Enhance the project's visual appeal and provide quick status insights by adding a Socialify banner and badges for deployment and tests to the README. Furthermore, include a section encouraging users to consider sponsoring the project to help support its ongoing development.

Steps:

1. Generate a project banner using Socialify.
2. Add the Socialify banner to the README.
3. Incorporate badges for deployment and tests status below the banner in the README.
4. Add a section in the README encouraging sponsorship with a link to the sponsorship page.

Acceptance Criteria:

• Socialify banner accurately represents the project and is visually appealing.
• Badges accurately reflect the current status of deployment and tests.
• A section for sponsorship is added, encouraging support for the project, with a clear call to action and link to the sponsorship page.
• README is updated to include the banner, badges, and sponsorship section, and displays them correctly.
• Create a PR with the updated README and ensure it adheres to the project’s STYLE_GUIDE.md.

Dependencies:

• Depends on the completion of Issue #8

Additional Context:

Enhancing the README with a banner, badges, and sponsorship section will not only make the project more engaging but also provide a pathway for financial support to ensure its continued development.

Separate Tests and CI into Different Workflows

To improve the organization and manageability of our automation processes, it's proposed to separate tests and Continuous Integration (CI) into distinct workflows. Currently, they are intertwined, making it hard to isolate issues and manage them independently. This separation will allow for more precise control and easier troubleshooting of each process.

Acceptance Criteria:

• Create a dedicated workflow for running tests, ensuring all tests are covered.
• Create a separate workflow for CI processes, such as build, lint, and deployment.
• Update any necessary documentation to reflect the changes in workflow setup.
• Ensure both workflows are correctly triggered on relevant events (e.g., push, pull request).
• Verify that both workflows operate correctly independently and in conjunction with each other.
• Create a PR with the new workflow files and updated documentation.

Additional Context:

Separating tests and CI into different workflows will not only improve the organization but also the clarity and manageability of our automation processes, making it easier to maintain and troubleshoot the project.

Implement GitHub Action for Dependency Management and Label Automation

We have identified a need to automate the management of issue dependencies and labels within our repository. The goal is to create a GitHub Action that will automatically check for dependencies whenever an issue is resolved, and update the labels on dependent issues accordingly.

Acceptance Criteria:

1. When an issue is closed, the GitHub Action should trigger and scan the repository for other open issues that have a dependency on the closed issue.
2. If the GitHub Action identifies an issue that depends on the closed issue, it should check if all dependencies of that issue have been resolved.
3. If all dependencies of an issue have been resolved, the GitHub Action should remove the on hold label from that issue.
4. Adequate logging should be provided to trace the actions performed by the GitHub Action.
5. Error handling should be implemented to manage any issues that arise during the process.

Tasks:

• Develop a script to parse issue descriptions and identify dependencies.
• Create a GitHub Action YAML file to define the workflow, including triggers and jobs.
• Integrate with the GitHub API to manage issue labels.
• Test the GitHub Action in a controlled environment to ensure it behaves as expected.
• Document the GitHub Action, explaining its purpose, how it works, and how to use it.

Notes:

• Consider using existing GitHub Apps or Actions as a starting point or for inspiration.
• Ensure the GitHub Action has minimal impact on repository performance.
• Ensure all interactions with the GitHub API are secure and adhere to GitHub's best practices.

Benchmarking axum-js Performance

As axum-js approaches feature completeness, it's crucial to benchmark its performance to understand its capabilities and identify any potential areas of optimization. This issue serves as a placeholder and outline for the benchmarking task to be revisited once the library is feature-complete.

Preliminary Steps (to be updated):

1. Identify key areas/aspects to benchmark (e.g., request handling speed, memory usage, etc.).
2. Choose or create benchmarking scenarios and datasets.
3. Select benchmarking tools and set up the benchmarking environment.

Acceptance Criteria (to be updated):

• Comprehensive benchmarks covering identified key areas.
• Benchmark results are documented and analyzed.
• ...

Dependencies:

• Feature completeness of axum-js.

Additional Context:

This issue will be further detailed and actioned upon once axum-js reaches a state of feature completeness. Benchmarking is a vital step to ensure axum-js performs optimally and is ready for production use.