Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added schema definitions, responses, support to JWT auth, Swagger UI and Docker environment #24

Merged
merged 60 commits into from
Feb 17, 2020

Conversation

sfelix-martins
Copy link

@sfelix-martins sfelix-martins commented Jan 29, 2020

Added

  • Added schema definitions for models (Defined on @model annotation on methods or controller).
  • Added responses based on routes http methods, @throws annotations and auth middleware.
  • Added support to JWT authentication.
  • Added Swagger UI with docs.
  • Added docker environment to development support.

Changed

  • Changed to get middlewares from controller too, instead of only from routes.
  • Changed command usage to don't print on console or set in file. Automatically will generate on public path and the docs will be available in /docs route.

Configuring

To download the package from fork just add the repository in your composer.json:

   "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/coopersystem-fsd/laravel-swagger"
        }
    ],

and change the package version to dev-master:

"require": {
        "mtrajano/laravel-swagger": "dev-master",
}

Run composer update and the code from fork should be downloaded.

Usage

Follow the instructions on README.

Closes #18 , #7

Samuel and others added 30 commits January 17, 2020 15:20
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Alan Christian <[email protected]>
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Alan Christian <[email protected]>
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Alan Christian <[email protected]>
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Alan Christian <[email protected]>
Co-authored-by: Odilon Garcez <[email protected]>
Changes the configs to generate and show Swagger UI to many API versions.
Changes the generate swagger docs command to generate the swagger files
to specific versions on public folder to access from SwaggerUI.

Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Alan Christian <[email protected]>
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Alan Christian <[email protected]>
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Alan Christian <[email protected]>
// 'http',
// 'https',
],
'basePath' => '/',
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

didn't want to assume the basePath of the application, especially since I don't know if most people using this will have their application be versioned but it's there as an option for them

return Str::replaceFirst($this->config['basePath'], '', $this->route->uri());
$uri = Str::replaceFirst($this->config['basePath'], '', $this->route->uri());

return Str::start($uri, '/');
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed bug where if the user added / as basePath it would strip out the leading / from the path in the swagger docs

@sfelix-martins
Copy link
Author

@mtrajano Thanks for good changes.

I saw that occurred and error on travis build. Here has an example that can help you.

@mtrajano
Copy link
Owner

@sfelix-martins oh nice yes that is a much nicer solution, I'll update ci

@mgamal92
Copy link

Can I help in changes to make the process fast ? because I need this PR to be merged to can use it

@sfelix-martins
Copy link
Author

@mtrajano Please, resolve the review conversations that you already handled, to be more easy to see the really pending reviews.

@mtrajano
Copy link
Owner

mtrajano commented Feb 10, 2020

@mgamal92 @sfelix-martins hey sorry will resolve the issues I tackled already. The 2 things missing that are the most pressing are: 1. changing the example data logic from create to make and add tests for those (can also kill the transaction logic). 2. for the logic of getting the model relationships we should definitely not be calling random model methods in order to not cause any side effects (can potentially increment things on the db, add/remove data, etc..). Potential solutions would be to either rely on the return type hints to be of instance HasOne etc.. (prefer this one) or rely on a new annotations, and again just adding tests for these.

Some other ones I was hoping to get to before merging are: 1. making ignoredRoutes also take regex since this was a feature before and we're removing it in this pr, 2. Making the response logic more flexible (being able to config these etc..), am currently working on this one and adding tests. Finally some general clean up and fixing the README documentation.

Sorry again for the time it's taking to merge this one, I was actually away at a conference last week so I only had a few hours here and there to get stuff out. I have a lot more time until Wednesday so I was hoping to merge it by then. But yes if you guys can tackle some of these I'd really appreciate it and it'd speed the process a lot. Thanks!

@mgamal92
Copy link

Please clarify what problem about response ?

@mtrajano
Copy link
Owner

@mgamal92 nothing per se, it would just be nice if the consumer could configure which route methods map to which response codes and what their descriptions are. But again, that could come at a future release. I already fixed the example logic and I'm working on the model relationships logic so the only thing left to do would be to fix the docs to match the new config structure and adding the ability to filter by regex (not just route name). This should hopefully be done by tomorrow 🤞

@mgamal92
Copy link

mgamal92 commented Feb 11, 2020 via email

DB::beginTransaction();

return factory(get_class($this->model))->create();
return factory(get_class($this->model))->make();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make is much safer, only creates an instance without making a connection to the db

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if it's more safer. Please, think about cases like that:

$factory->define(App\Post::class, function ($faker) {
    return [
        'title' => $faker->title,
        'content' => $faker->paragraph,
        'user_id' => function () {
            return factory(App\User::class)->create()->id;
        }
    ];
});

If think we should to use transactions to avoid surprises...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked here other reasons to use create instead of make. We done it to generate the example data to timestamps and id fields too. I don't know if it sufficient... bus was one of the reason.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test that check the example response is checking just if the result is not null. But I think that the correct behavior should check if is not empty. If apply this change the build will fail with the make method, because empty values in created_at, updated_at na id properties.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh good point on the user_id example, I guess we can't avoid a transaction here. I'll change this back to what it was. Reasons I was trying to avoid create even with the transaction are 1. to avoid having to make a connection to the db to generate static data, 2. it doesn't necessarily leave the db in an unchanged state (one example being the AUTO_INCREMENT value that remains unchanged even with a rollback) so it might just be some extra side effects that the user might not be expecting when running this. We might also want to add a config to disable this part by default and let the user manually turn it on if he chooses to, along with some prominent warnings not to run this in a prod environment (which should be obvious but we can't always guarantee that).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I allow. I think we can maybe too ask user a different DB connection just to generate the docs... what about it?

if (is_subclass_of($relation, Relation::class)) {
$type = (new ReflectionClass($relation))->getShortName();
if (is_subclass_of($returnTypeClass, Relation::class)) {
$relation = $method->invoke($model);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still not ideal but slightly safer than before. It at least checks the return typehint of the method before invoking it. Am also going to add a config to disable this by default and add a warning on the docs that this will invoke methods in the model to get the relation name.

@mtrajano
Copy link
Owner

Pushed some more changes out, only thing missing is just to fix the README and add a config called parseModels to disable invoking the model methods by default. Thanks for bearing with me all

{
return $this->belongsTo('Mtrajano\LaravelSwagger\Tests\Definitions\Customer');
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

going to clean up these tests and move them to the stubs namespace during a later refactor after the merge

*/
private $shouldParseRelationshipDefinitions;

public function __construct(Route $route, array $errorsDefinitions = [], $shouldGenerateExampleData = false, $shouldParseRelationshipDefinitions = false)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sfelix-martins let me know what you think. If this works for you then I just need to revert that other change, fix the documentation and we can finally merge this soon 🙌

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mtrajano To me it looks good to leave it in the user's hands

@mtrajano
Copy link
Owner

mtrajano commented Feb 17, 2020

@sfelix-martins Sorry for the late response to this. I fixed the docs to match the match the new config layout. However there are still a couple of flaky tests ever since you changed the assertion to check that the example property is empty vs null. It always passes locally but seems to fail every now and then in CI, I tried sshing into a 7.2/7.3 php docker container and tried running the test there but it was still passing pretty consistently. So I chose to skip those tests for now.

I don't want to keep this pr open much longer and keep adding changes to this since I think it's getting a little out of control so I opened a v0.7 branch and I think we can merge to that in the meantime. I'll cut a dev release for 0.7 that way people who want to use/test the new features are able to do so and we're able to clean up, fix the tests, etc.. and when it's stable we'll merge it into master, does that sound ok? I'll also add you guys as collaborators as well, thank you so much for this awesome pr and sticking around!

@mtrajano mtrajano changed the base branch from master to v0.7 February 17, 2020 04:36
@sfelix-martins
Copy link
Author

@mtrajano ok man. It looks good. Thank you for develop this very good package. I think we can finally merge.

@mtrajano mtrajano merged commit bd42122 into mtrajano:v0.7 Feb 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for Swagger UI - view the generated docs
4 participants