ahmedesa / laravel-api-tool-kit

Your all-in-one solution for building efficient APIs with Laravel.

Hi 👋, I'm Ahmed Esa

A passionate Backend developer from Egypt

• 🌱 I’m currently learning GoLang

• 👯 I’m looking to collaborate on Open Source Projects

• 💬 Ask me about PHP ,Laravel

• 📫 How to reach me [email protected]

Blogs posts

• Automated Laravel Deployment to cPanel via GitLab CI/CD and Envoy
• How to Use Amazon SES V2 in Laravel: Benefits and Implementation Guide
• Laravel Dynamic Pagination

Connect with me:

Languages and Tools:

 

laravel-api-tool-kit's Issues

Standardize Error Responses

I've noticed that changing the exception handler from "ExceptionHandler" to "APIHandler", it works fine on dev mode, but when it goes into production mode, I only receive server error with code 500 instead of the actual error. Which sometimes is a Validator error.

Kindly explain why it's so.

By the way, I love this package. Greate job.🫱🏼‍🫲🏽

Can we return the Code?

{
  "status": 200,
  "message": "your resource successfully",
  "data": [
    ...
  ]
}

Implement generate:service Artisan Command

Description:
We aim to simplify the process of adding new external services to your application by introducing the generate:service Artisan command. This command will automate the creation of essential files for a new service, following a predefined structure.

Steps to Implement:

1. Command Structure:

   • Create the generate:service Artisan command with appropriate options and prompts.

2. Service Name Prompt:

   • Add a prompt to collect the name of the new service when running php artisan generate:service.

3. File Generation:

   • Implement logic to generate the following files based on the provided service name:
     • ServiceNameService.php (Main service class)
     • ServiceNameMock.php (Dummy/mock service class)
     • ServiceNameServiceProvider.php (Service provider class)
     • service-name.php (Configuration file)

4. File Content:

   • Define the initial content for each generated file, providing a template structure for contributors.

5. Class Namespacing:

   • Ensure proper namespacing for the generated classes.

6. Configuration File:

   • Include placeholders or default configurations in the service-name.php file for contributors to customize.

7. Unit Tests:

   • Develop unit tests for the generate:service command to ensure its functionality and reliability.

8. Documentation:

   • Update the package README and documentation to include information on using the generate:service command.

Add config featue for api/V1/frontend and api/V1/backend.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

add support to different disks in Mediahelper class

Exception Handler no longer works in laravel 11

Describe the bug
Exception Handler no longer works in laravel 11. Actually I never tried your package in laravel 10, but u guess it works there, because the changes are in 11.

To Reproduce

1. Create any request that fails validation

Expected behavior
To receive the expected json

Additional context
I've followed the install instructions by creating app\Exceptions\Handler.php
and adding there

namespace App\Exceptions;

use Essa\APIToolKit\Exceptions\Handler as APIHandler;

class Handler extends APIHandler
{
}

But when i test i get the default laravel error instead of the expected package error
This is what i get as a response

{
    "message": "The email has already been taken. (and 1 more error)",
    "errors": {
        "email": [
            "The email has already been taken."
        ],
        "terms": [
            "The terms field is required."
        ]
    }
}

When using HasManyThrough and dynamicPaginate - wrong (duplicate) records are returned

Describe the bug
If you take the laravel docs example https://laravel.com/docs/11.x/eloquent-relationships#has-many-through
and do
$project->deployments()->useFilters()->dynamicPaginate();

Then all the results will show only the first deployment. The count is correct.
If I change it to
$project->deployments()->useFilters()->get();
then then it works correctly.

I've also tested and it works correctly for a different hasMany relation.

So I tried to find a fix and I found that if I change

$results = ($total = $this->toBase()->getCountForPagination())
                ? $this->forPage($page, $perPage)->get(['*'])
                : $this->model->newCollection();

to

$results = ($total = $this->toBase()->getCountForPagination())
                ? $this->model->forPage($page, $perPage)->get(['*'])
                : $this->model->newCollection();

in MacroServiceProvider.php then issue is fixed, but it brakes the hasMany relation. It starts to show all rows instead of the related, but counts them correctly.

To Reproduce
replicate
https://laravel.com/docs/11.x/eloquent-relationships#has-many-through
and do
$project->deployments()->useFilters()->dynamicPaginate();

Expected behavior
To show expected records

New Logo

Add Documentation Section for Traits

Currently, our package includes several traits that can be useful in your application. To enhance user understanding and promote contributions, we need to add a new section in the documentation that describes how the following traits work:

1. HasActivation.php
2. HasCache.php
3. HasCreatedBy.php
4. HasGeneratedCode.php
5. HasOrder.php
6. Sluggable.php

Tasks:

• Create a new section in the documentation specifically for traits.
• Write detailed explanations for each trait, covering their purpose and usage.
• Provide code examples to illustrate the implementation of each trait.
• Ensure that the documentation is clear and accessible for developers of varying expertise levels.
• Update the README and main documentation index to include a link to the new section.

Enums in schema is not generated probably

I tried to use this command to create new Product model with migration file but Enum type is not generated probably.

Command:

php artisan api:generate Product "name:string:unique|description:text:nullable|image:string|status:enum:in-stock,finished" -mf

Result:

public function up(): void
{
    Schema::create('products', function (Blueprint $table) {
        $table->id();
	$table->string('name')->unique();
	$table->text('description')->nullable();
	$table->string('image');
        // Attention: Check the syntax for enum definition below
	$table->enum('status')->in-stock,finished();
            
        $table->timestamps();
     });
}

Types

Hey

Can you refine the data types accepted by the methods in ApiResponse?

For example:

if($validateUser->fails()){
      return $this->responseBadRequest($validateUser->errors(), 'Validation Error');
}

Larastan returns:
phpstan: Parameter #1 $details of method App\Http\Controllers\Api\V1\Auth\RegisterController::responseBadRequest() expects null, Illuminate\Support\MessageBag given.
phpstan: Parameter #2 $message of method App\Http\Controllers\Api\V1\Auth\RegisterController::responseBadRequest() expects null, string given.

The IDE states that the only allowed type is null, of course the code works, but it causes errors in larastan which doesn't help in maintaining good quality of the code, if I'm wrong and it can be set properly please let me know how.

Versioning

I think it would be helpful to introduce a well thought out versioning into the package. It is known that you provide an API and it comes to breaking changes, but here you do not want to push the users of the API in front of the head, so you rely on versioning. I think this would be a useful feature in the long run. :)

Versioning could be done via HTTP header or also via url. Or a middleware that lets an API user determine the version based on a database field matching the token.