Progress about lighthouse HOT 13 CLOSED

Hi @Gugudesaster,

At this point in time Lighthouse has more testing than my other package, but the API could change at any time before the v1.0 release. So Lighthouse is more stable than my other package, but you won't have to worry about changes with laravel-graphql-relay.

It's been a bit difficult to work this in with my daily job, but I do plan on supporting this package for the foreseeable future.

I'm hoping back on a project that relies on Lighthouse so hopefully I'll be able to tag a v1.0 release in the not too distant future.

I'll keep this issue open until I tag that release.

Let me know if you have any other questions. Thanks @Gugudesaster!!

from lighthouse.

Hi @chrissm79 ,
thx 4 answering.
Sounds great. I don't mind a few changes.
Do I use it similar to laravel-graphql-relay?
Can I use the documentation there as basis or do you have a small example I can borrow?

thank you so much for the work you put in this awesome package.

from lighthouse.

@Gugudesaster You should look at the unite tests for documentation. I finished building a full Laravel integration with Lighthouse with the use of the tests as good examples of how things are implemented. There are also a good amount of similarities between how this project is structured and the laravel-graphql-relay project, so in some cases those docs are pretty useful.

from lighthouse.

Thanks @alexwhb!

@Gugudesaster, the tests will indeed be the best way to determine how to get up and running w/ Lighthouse. laravel-graphql-relay is similar, but looking through the tests will give you the most insight.

v1.0 of Lighthouse will include full docs

from lighthouse.

Perfect. I'll look into it, thanks. :)

from lighthouse.

@Gugudesaster Just a quick update... I completed probably my largest hurdle which was creating a DataLoader to help prevent a N+1 issue when working with nested connections. I'm going to test it out on a project I'm working on and if all goes well I should start working on documentation this week. Once the docs are done I'll tag and release v1.0!

from lighthouse.

Hi, how are you getting on with the docs?

from lighthouse.

@Gugudesaster @darrenmerrett @alexwhb I apologize for the delay, but I didn't want to respond until I actually had something to show. I started the documentation for this package. I intend to include a walkthrough that will take you from zero to a fully functional GraphQL server that should help explain how to get your project up and running.

I'm currently waiting for graphql-php v0.9 to be tagged and then I will update this package with a v0.8 release which includes Deferred/DataLoader and some minor fixes.

Let me know if you have any questions, and thanks for the interest!

from lighthouse.

Hey @chrissm79,

Hijacking this issue a little as I don't want to open another for just casual conversation about this package :)

This seems really interesting. I'm liking that you're keeping relay support at the forefront but not restricting the package to relay compliance only.

Are you able to elaborate a bit on the DataLoaders functionality as that seems to be a major feature here? I've looked through the tests but i'm still confused about what they're actually doing. Basically I'm curious as to what I would gain using this package instead of Folkloreatelier/laravel-graphql assuming I'm not using relay of course.

from lighthouse.

Hey @hailwood

You're dead on, it's a pretty cool feature and deals with the biggest problem I had with GraphQL. When querying nested lists or connections in GraphQL you can run into some pretty nasty N+1 issues. Check out this page from the docs to see an example.

The DataLoader in this package uses graphql-php Deferred solution (which is amazing) to batch fields together so you can optimize your queries. So let's say you have the following query:

company {
    users(first: 10) {
        #...
        tasks(first: 5) {
            #...
        }
    }
}

Getting the companies first 10 users is no problem, however, when GraphQL gets to your user's tasks, it will call the resolve function 10 times in this case, which is 10 queries to your DB. You could do something like eager load your tasks on your users, but what if they have hundreds or thousands of tasks... that's a ton of unnecessary data. So what DataLoader does is allow you to pass in a key (for example, the id of the user) and then resolve all of the user's tasks at one time. So now you went from 10 DB calls down to 1!

The next problem this package solves is eager loading relationships with limits. Consider the following (in Laravel)

$users->load(['tasks' => function ($q) {
    $q->take(10);
})->get();

You would think you would get 10 tasks per each user, but actually you get the first 10 tasks total. This package adds a fetch macro to collections which takes care of this problem. However, I've only tested in MySQL and it does not work with SQLite.

So now you can do the following:

$users->load(['fetch' => function ($q) {
    $q->take(10);
})->get();

Each user will have the first 10 tasks eager loaded (single query to the DB)!

The DataLoader is where I left off in the docs and I'm hoping to get to it this weekend. I also haven't tagged a new release yet as I'm waiting on graphql-php to cut v0.9.0 to include Deferred.

Hopefully that all made sense, but let me know if you still have questions!

from lighthouse.

@chrissm79 so I recently was doing a bit of searching around for possible solutions to the graphQL subscription system... I wanted to find a way to do it without using Redis. I came across this: https://github.com/clue/php-socket-raw, which is a high level abstraction of the PHP sockets implementation. I've not yet looked into how this would work with relay, but it seemed promising. Let me know your thoughts if you get some time.

from lighthouse.

@alexwhb This does look pretty interesting. I'll need to dig into it after I get a few small items flushed out, but it certainly seems like a possible solution. Ideally, I would like to have a built in solution (such as laravel-echo-server) as well as a 3rd party (such as Pusher). That way if someone feels comfortable running a websocket server themselves (and at no additional cost) it's easy to do so and for those that don't want to deal with the extra hassle there's a solution for them as well.

The next step is determining how to get Echo/Node/Pusher to work with the graphql server (i.e., GraphQL queries that exist on the PHP server). I haven't even started to go down that path yet, but I came across this article and although it does rely on Redis it may pave the way to setting up subscriptions in Laravel/Echo.

I'll likely move this conversation to a new issue once I have some other items cleared off my plate but thanks again for the feedback!

from lighthouse.

@chrissm79 excellent! I'll check it out. Ya ideally it wold probably be a good idea to abstract that implementation with an interface, so you can use what ever implementation suits your needs best, but it's nice to know that it's possible to do an in PHP solution. I'll try to dig into it a bit more when I get some time.

from lighthouse.