Lighthouse: Since v2.5, the `@middleware` directive does not work with Lumen

[ta-toshio]

Describe the bug
in MiddlewareDirective.php, call getMiddleware() and getMiddlewareGroups().
but Laravel\Lumen\Routing\Router does not have getMiddleware and getMiddlewareGroups function.

Router of lumen: https://github.com/laravel/lumen-framework/blob/5.7/src/Routing/Router.php

Output/Logs
Call to undefined method Laravel\Lumen\Routing\Router::getMiddleware() in /app/lumen/vendor/nuwave/lighthouse/src/Schema/Directives/Fields/MiddlewareDirective.php:167

Environment
Lighthouse Version: from 2.5
Lumen Version: ^5.7
PHP Version: 7.2.11

[spawnia]

I am not too familiar with Lumen and have some more pressing issues to resolve at the moment.

Anyone that feels qualified can give it a shot. If it is possible to find a way of dealing with middleware that works with both Lumen and Laravel, that would be the best. I guess it could automatically detect what app('router') returns and act accordingly.

• Implementation: https://github.com/nuwave/lighthouse/blob/master/src/Schema/Directives/Fields/MiddlewareDirective.php

• Tests: https://github.com/nuwave/lighthouse/blob/master/tests/Unit/Schema/Directives/Fields/MiddlewareDirectiveTest.php

[4levels]

I'll try to look into this soon. I'm currently not blocked by this (but my latest composer update was from a couple of weeks ago) and working with React Native has it's own set of challenges to tackle.

_I'm still wondering why so little people use Lumen with Lighthouse since Lighthouse is an API only library just like Lumen. Anything that works in Lumen will guaranteed work in Laravel, but not the other way around. Lumen is also so much faster, just try to var_dump a request object from Laravel..._

[matrunchyk]

Hi @4levels, did you have a chance to take a look at it? Thank you!

[Inkybro]

A co-worker and I looked into this today. We really would have loved to do away with the Laravel bloat on our little project. Unfortunately, app('router') resolves down differently. In other words, Lumen and Laravel treat routers completely different. Forgive me, if you're well aware of this. We're new to digging in and commenting on open source stuff.

Anyway, we messed around with it for a good three hours, and we couldn't find any way to expose the same information as Laravel would provide. In Laravel, we define stuff in Kernel.php that is basically returned in the getMiddleware() and getMiddlewareGroups() method. Those defined things are simply returned by Laravel's "router".

We couldn't find any way to access the same kind of data, even "hackily", via Lumen.

I'd love if @4levels could take a look at this because I've seen his or her name pop up continuously in the context of Lumen + Lighthouse.

If anyone wants to give us any clues we're bloodhounds and we had a great time trying to get to the bottom of this today.

If not, I'd still love to know. It's driving me crazy. It seems insane to me that Lumen doesn't provide a way to do this, when Laravel does.

Is this more a pull request for Lumen itself??? That's kind of the conclusion I ended up coming to, a few hours ago. Everything is protected, and there are no accessor functions to get middleware data, and even if there were, the middleware data wouldn't come back the same as it does from Laravel. So, I'm really just not sure how to approach the issue (again, new to "helping out" on open source stuff).

At the end of the day, app('router') will resolve to two totally different classes (probably pretty obvious), and those two classes behave in no way like one another from what we could tell. Laravel provides much more exposure. Lumen seems to provide literally none.

Would love to hear back on this. Best wishes.

[4levels]

Hi guys,

I've been very busy lately but I'm definitely going to look into this. I almost feel like I'm on a crusade for Lumen to be the default driver for any lightweight or API Laravel library (looking at you, laravel-websockets). The same goes for the use of facades in library land.
From what I've experienced Laravel puts a lot of magic into the router (hence var_dumping it fails miserably), pulling in various dependencies (see eg. the single use temp routes).

I'll keep you posted & thanks for looking into this..

[4levels]

Hi Guys,

I'm back on track. However, since delivering is currently a big priority, I decided to ditch my current Lumen setup and start using Laravel (even with facades) instead since I really need to focus on the client side (React Native) part of my pet project. So for now I won't be using Lumen anymore since the porting of the various libraries to work with Lumen is way to time consuming and frustrating for me.

"better is the enemy of good" or "done is better than perfect"

Ofcourse, once things are up and running (with a published app in the app stores) I'll be looking into this once again. I'm very happy to hear that there might be an intention to migrate from Laravel to Lumen as I truely believe Lumen is the better candidate to support Lighthouse.

Keep up the great work everyone and sorry to let this slide for the moment..

[e200]

I'm getting this error too. :(

I'm being forced to leave my mutations opened because I can't apply an auth middleware.

[e200]

@Inkybro, @4levels, @spawnia a solution for this issue would be create 2 different service providers (one for Lumen and other for Laravel) each one providing different solutions (with the same contract) for each Framework instead of provide a generic solution for both (since their differs to much).

Another thing is that the @rules directive isn't working in Lumen because Lumen has a different Validation method with Laravel. It would be also resolved providing a different @rule trough a LighthouseLumenServiceProvider.

[e200]

Instead of hard code witch @rule class will be resolved, you can decouple it and let the provider provide the best class to handle this directive (and consequently solve the @rules issue on Lumen).