4 ms·

Indeed. Also, I have been looking for GraphQL implementations for other server-side languages recently and I have yet to encounter a schema-first implementatio

Indeed. Also, I have been looking for GraphQL implementations for other server-side languages recently and I have yet to encounter a schema-first implementation that comes close to what the Lighthouse layer for Laravel can do. That is really productive.

aglione 3y ago
have a look to http://strawberry.rocks http://strawberry.rocks for Python. I've still to find a better code first implementation too
- bemusedthrow75 3y ago
  This is one I did look at and then forgot about -- thanks!
withinboredom 3y ago
Why would you want to use graphql? In my experience, it’s pretty terrible for real-world use-cases.
- bemusedthrow75 3y ago
  Lighthouse is sophisticated and productive. I only use it in fully-authenticated contexts but because it is schema-first with good ORM bindings and excellent annotation support, I barely write any logic that isn't a mutation, an accessor or a permissions gate. The occasional top-level query resolver. Beyond that it is the graphql schema and the models. And it gives me the opportunity to separate out the front end concerns in a way I could explain to someone else. Apollo has been a bit of a pickle on the front-end, mind you. That's a decision I'd revisit. But generally it has meant a flexible API interface and leads to nice low latency UIs. Check it out: https://lighthouse-php.com https://lighthouse-php.com And these really good third-party auth mutations for Passport: https://lighthouse-php-auth.com https://lighthouse-php-auth.com
  - withinboredom 3y ago
    Ah cool! I hadn't seen this before! I'd only seen fairly raw GraphQL from like 4-5 years ago, when you had to write your own auth, resolvers, deal with n+1 queries, etc. This is actually really nice and solves a lot of the issues I was thinking of.
    - bemusedthrow75 3y ago
      Right. People keep telling me that code-first is better but there is no way all those complex APIs are easier to use than just spitting out some JSON from an endpoint. Schema-first feels more manageable. I'm not going to say I haven't had to do that a _bit_ here, when I've got into quite advanced things. (e.g. sometimes you might want to dynamically provide the values from an enum, or write your own decorators, or you might want a custom top-level resolver.) It's built on the WebOnyx reference implementation, so there's some help out there. But it's amazing how much code I haven't had to write, and being the sort of person I am with difficulties controlling focus, I absolutely love the schema-first approach. It interacts well with Eloquent scopes, with the ordinary API gate system, with policies and validations. It's actually weird how good it is. You still have all the same issues you have with GraphQL generally (like limiting graph traversals to things a user is authorized to see), but you have so many tools.
      - withinboredom 3y ago
        Another nice thing about schema-first is that clients can start interacting with a mock server from day-0, and both sides can build out the implementation independently according to the spec. It really speeds things up on larger projects (IMHO). Working on FrankenPHP, we get a lot of issues from the Laravel people (mostly in regards to octane + worker mode), and I've been getting into more and more Laravel to support these folks and understand what is going on in the SAPI. I've really started to understand the attraction lately. Previously, I worked at Automattic for quite a while and learned the WordPress side of PHP, then worked with Symfony in a corporate setting, so I've yet to get into Laravel in the commercial world, but I'm thinking I probably will for my next job.
    - 3y ago

aglione 3y ago

have a look to http://strawberry.rocks http://strawberry.rocks for Python. I've still to find a better code first implementation too

bemusedthrow75 3y ago
This is one I did look at and then forgot about -- thanks!

withinboredom 3y ago

Why would you want to use graphql? In my experience, it’s pretty terrible for real-world use-cases.

bemusedthrow75 3y ago
Lighthouse is sophisticated and productive. I only use it in fully-authenticated contexts but because it is schema-first with good ORM bindings and excellent annotation support, I barely write any logic that isn't a mutation, an accessor or a permissions gate. The occasional top-level query resolver. Beyond that it is the graphql schema and the models. And it gives me the opportunity to separate out the front end concerns in a way I could explain to someone else. Apollo has been a bit of a pickle on the front-end, mind you. That's a decision I'd revisit. But generally it has meant a flexible API interface and leads to nice low latency UIs. Check it out: https://lighthouse-php.com https://lighthouse-php.com And these really good third-party auth mutations for Passport: https://lighthouse-php-auth.com https://lighthouse-php-auth.com
- withinboredom 3y ago
  Ah cool! I hadn't seen this before! I'd only seen fairly raw GraphQL from like 4-5 years ago, when you had to write your own auth, resolvers, deal with n+1 queries, etc. This is actually really nice and solves a lot of the issues I was thinking of.
  - bemusedthrow75 3y ago
    Right. People keep telling me that code-first is better but there is no way all those complex APIs are easier to use than just spitting out some JSON from an endpoint. Schema-first feels more manageable. I'm not going to say I haven't had to do that a _bit_ here, when I've got into quite advanced things. (e.g. sometimes you might want to dynamically provide the values from an enum, or write your own decorators, or you might want a custom top-level resolver.) It's built on the WebOnyx reference implementation, so there's some help out there. But it's amazing how much code I haven't had to write, and being the sort of person I am with difficulties controlling focus, I absolutely love the schema-first approach. It interacts well with Eloquent scopes, with the ordinary API gate system, with policies and validations. It's actually weird how good it is. You still have all the same issues you have with GraphQL generally (like limiting graph traversals to things a user is authorized to see), but you have so many tools.
    - withinboredom 3y ago
      Another nice thing about schema-first is that clients can start interacting with a mock server from day-0, and both sides can build out the implementation independently according to the spec. It really speeds things up on larger projects (IMHO). Working on FrankenPHP, we get a lot of issues from the Laravel people (mostly in regards to octane + worker mode), and I've been getting into more and more Laravel to support these folks and understand what is going on in the SAPI. I've really started to understand the attraction lately. Previously, I worked at Automattic for quite a while and learned the WordPress side of PHP, then worked with Symfony in a corporate setting, so I've yet to get into Laravel in the commercial world, but I'm thinking I probably will for my next job.
  - 3y ago