-
Notifications
You must be signed in to change notification settings - Fork 70
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
Conversation
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]>
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Odilon Garcez <[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]>
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Odilon Garcez <[email protected]>
Co-authored-by: Odilon Garcez <[email protected]>
// 'http', | ||
// 'https', | ||
], | ||
'basePath' => '/', |
There was a problem hiding this comment.
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, '/'); |
There was a problem hiding this comment.
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 oh nice yes that is a much nicer solution, I'll update ci |
Can I help in changes to make the process fast ? because I need this PR to be merged to can use it |
@mtrajano Please, resolve the review conversations that you already handled, to be more easy to see the really pending reviews. |
@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 Some other ones I was hoping to get to before merging are: 1. making 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! |
Please clarify what problem about response ? |
@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 🤞 |
So I understood from that, the PR will be finished merged tomorrow,
right?
…On Tue, Feb 11, 2020, 4:05 AM Mauricio Trajano ***@***.***> wrote:
@mgamal92 <https://github.com/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
🤞
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#24?email_source=notifications&email_token=AHWBLWAEQSNSF2UAGICSLK3RCIBYJA5CNFSM4KNJELW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELK7WGY#issuecomment-584448795>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHWBLWDNECFJ2KDREKMJGD3RCIBYJANCNFSM4KNJELWQ>
.
|
DB::beginTransaction(); | ||
|
||
return factory(get_class($this->model))->create(); | ||
return factory(get_class($this->model))->make(); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
Pushed some more changes out, only thing missing is just to fix the README and add a config called |
{ | ||
return $this->belongsTo('Mtrajano\LaravelSwagger\Tests\Definitions\Customer'); | ||
} |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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 🙌
There was a problem hiding this comment.
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
@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 ok man. It looks good. Thank you for develop this very good package. I think we can finally merge. |
Added
@model
annotation on methods or controller).@throws
annotations andauth
middleware.Changed
/docs
route.Configuring
To download the package from fork just add the repository in your
composer.json
:and change the package version to
dev-master
:Run
composer update
and the code from fork should be downloaded.Usage
Follow the instructions on README.
Closes #18 , #7