Api: Maintaining dingo/blueprint

Created on 25 Sep 2017  路  8Comments  路  Source: dingo/api

@from2day @thilanga In Issue 1428 (Call For Maintainers) I offered my help with dingo/blueprint. I'd like to discuss what could be done.
I support the idea of making dingo/blueprint standalone. It could and should of course still be part of dingo/api but all the dingo/blueprint specific code (service provider, artisan command etc) should IMO be extracted to dingo/blueprint. Compatibility with the newest versions of Laravel should always be prioritized and issues should be taken care of (either being solved or closed). There are some interesting open issues that would complete API Blueprint features like adding support for the overview and metadata sections. How do you see dingo/blueprint's place and further development?

discussion

Most helpful comment

Some questions (sorry to burst into your chat :) )

  1. Should we start by removing blue print dependency from dingo/api
  2. what do you think about OpenAPI? It turned to a mature 3.0 version and ecosystem looks much richer

All 8 comments

si patron

Thanks for the replay.

I totally agree on your idea, that dingo/blueprint should work as a standalone package. I was surprised too at first that commands come from dingo/api only.
I haven't tried yet to separate them and check how deeply coupled they are. But this could be one of the first things to do.

I've tried your laravel-blueprint-docs generator it works nice.

About features:

  • That overview section I hope we will merge as soon as it tested.
  • The metadata section is still a new topic for me, but it is a really important one.
  • What about multiple files rendering or including parts as separate files?

Anything else?

For the start it seems we do share the same vision. And there are clear tasks already.

Some questions (sorry to burst into your chat :) )

  1. Should we start by removing blue print dependency from dingo/api
  2. what do you think about OpenAPI? It turned to a mature 3.0 version and ecosystem looks much richer

@catalinux OpenApi is something I always interested in. Can you create a seperate issue and label as discussion.

We can talk about it there

With your support, I will work on a pull request that pulls over dingo/blueprint specific code from dingo/api (and make it work in Laravel 5.5). @from2day Go?

Just to add, blueprint code actually got run on every request. This doesn't sound like good to performance.

@jasonlewis @M165437 I really appreciate your work, but what's the status?
Cause for now the api:docs command is generally faulty. It fits FORMAT 1A to some extent, but generated docs are rather useless.
So, if not maintained, I think it would be better, to remove it from documentation.
BTW. @jasonlewis I tried slack channel, but I can't notify you, so in this regard, dingo readme should be updated also

I have been wanting a Swagger / OpenAPI integration for a long time. I think it should also be in its own repo as an extension (same with Blueprint). Should not have things in the core package not everybody use and is not deemed essential for the project.

Was this page helpful?
0 / 5 - 0 ratings