getcronit / pylon

A code-first approach to GraphQL API development

⚠️ Pylon Requires Bun: This project currently depends on the Bun runtime. If you need support for a different runtime, please upvote and follow the discussion on Issue #6 to help us prioritize it.

From Functions to APIs - Instantly

The GraphQL schema is generated in real-time from your TypeScript definitions, allowing you to focus solely on writing your service logic. This approach significantly improves development speed, enhances type safety, and reduces errors.

Any breaking changes in your code are instantly reflected in your API, enabling you to immediately see how changes impact its functionality.

Head over to pylon.cronit.io to explore features and documentations!

Get involved

Documentation, bug reports, pull requests, and other contributions are welcomed! See CONTRIBUTING.md for more information.

Getting help

• Community Support: Join the Pylon community on GitHub to report bugs and request features.
• Professional Support: For professional support and consulting services, contact [email protected].

---

Pylon is brought to you by Cronit.

pylon's Issues

Unhandled Exception Causes Restart Requirement

Describe the bug
An unhandled exception causes the process to exit with code 1, requiring a manual restart of the pylon server.

To Reproduce
Steps to reproduce the behavior:

1. Go to src/index.ts
2. Explicitly throw an error

Expected behavior
The process should handle the exception gracefully and provide a clear error message without requiring a manual restart. Ideally, the development server should continue running, allowing the developer to fix the issue and retry without restarting the entire process.

Screenshots

Desktop:

• OS: MacOS Sonoma 14.5

[Bug] An error occurs when applying TypeORM

Describe the bug
An error occurs when importing Typeorm after installation.
(But no error occurs in the case of import type {...} from "typeorm")

To Reproduce
Steps to reproduce the behavior:

# typeorm install
bun add typeorm

# run
bun run develop

Expected behavior

Bundling Pylon: ./src/index.ts...
Bundling Pylon: done
17060 | // Save OS-specific path separator
17061 | var sep = path.sep;
17062 | 
17063 | // If we're in webpack, force it to use the original require() method
17064 | var requireFunction = ( true)
17065 |         ? eval("require")
               ^
ReferenceError: Can't find variable: require
      at 50658 

Screenshots

import TypeORM

package.json

Desktop (please complete the following information):

• OS: MAC
• versions:
  • "@getcronit/pylon": "^1.1.1"
  • "@getcronit/pylon-builder": "^1.0.1"
  • "@getcronit/pylon-cli": "^1.0.0"
  • "@getcronit/pylon-server": "^1.0.0"

Additional context
Hello.

I found out about this pylon while using Hono + TRPC.

This has the advantage of forming an API with a truly attractive concept.
In the case of graphql, there were some disadvantages to creating a gql schema, but through hono + pylon, the graphql schema is automatically created through typescript and quick graphql construction is possible, which has the advantage, so I would like to apply it to the project as soon as possible.

Is there any way to solve this?

feat: Use `requireAuth` as a Function Directly

Is your feature request related to a problem? Please describe.
I'm always frustrated when I can only use the requireAuth decorator inside classes. This limitation makes it difficult to implement authentication checks in functional programming paradigms or in cases where classes are not needed.

Describe the solution you'd like
I would like the requireAuth function to be usable directly, not just as a decorator. This would allow developers to wrap any function with requireAuth for authentication checks without the need to define a class. For example:

const test = requireAuth({}, () => {
  return "test";
});

Describe alternatives you've considered
An alternative could be to create a higher-order function that handles the authentication logic, but this requires additional boilerplate code and does not leverage the existing requireAuth logic.

Additional context
Currently, it is only possible to check for authentication when using the requireAuth decorator due to the nature of TypeScript decorators, which can only be used inside classes.

Example with the current implementation:

import { requireAuth } from "@getcronit/pylon";

class Test {
  @requireAuth()
  static test() {
    return "test";
  }
}

Desired implementation:

const test = requireAuth({}, () => {
  return "test";
});

This feature would streamline authentication checks and make the requireAuth function more versatile and user-friendly.

Preserve Original Error in ServiceError Class

Is your feature request related to a problem? Please describe.

I'm always frustrated when the ServiceError class swallows the original error, making it impossible to build a complete stack trace. This behavior limits the ability to effectively debug and trace issues back to their origin.

Describe the solution you'd like

I suggest enhancing the ServiceError constructor to accept a third property called error, which will be assigned to this.cause. This change will preserve the original error and provide more context when handling errors.

Describe alternatives you've considered

An alternative solution could involve manually attaching the original error to the ServiceError instance in every catch block. However, this approach is cumbersome and error-prone compared to having built-in support within the ServiceError class itself.

Additional context

Here is a proposed change to the ServiceError class:

class ServiceError extends Error {
    constructor(message, code, error = null) {
        super(message);
        this.code = code;
        this.cause = error;
    }
}

Usage Example:

try {
    // Some operation that may throw an error
    throw new Error("Original error message");
} catch (err) {
    throw new ServiceError("Service failed", 500, err);
}

In this example, the original error is preserved within the ServiceError instance, allowing for better debugging and error handling.

Benefits:

• Improved debugging: Retains the original error, making it easier to identify the root cause.
• Enhanced error handling: Developers can access the original error details if needed.

Non-bun options

The requirement for using Bun is a limitation as it can't be run on cloudflare workers or the like. Are there any plans to support any other runtimes? I am really eager to use this in my project however introducing Bun will add needless complexity to our architecture.

Thanks