Fork me on GitHub
#luminus
<
2018-03-16
>
okwori11:03:59

Has anyone manage to get Lacinia graphql implementation to work with luminus?

okwori11:03:03

Including getting the Docs explorer of GraphiQL to work with the query root and schema.

eggsyntax14:03:01

Hey @simon I've recently started a new project with luminus +graphql. Graph/i/QL is working out of the box, including the docs explorer (although it took me a while to figure it all out, including the existence of the graph/i/ql component 😉 ). I'm not sure from what you said whether you're wanting to actually use lacinia-pedestal, or you're just using it as an example -- my (offhand) impression was that it made sense to pick either l-p or luminus +graphql, that they wouldn't necessarily play well together. If you want to describe what's happening when you try to use the docs explorer, I'm happy to see if I recognize the problem.

okwori17:03:54

@U077BEWNQ Thanks for trying to hack it with me. Firstly, I was referring to lacinia-pedestal because with that you didn't need to border about graphiql and it comes served. I would like us to have something like that here also, (a possibility of hacking that into ours using mount, not sure yet how to do it or if it is a good idea). That said, I am using luminus +graphql, setup a simple schema, resolversusing the inbuilt star-war schema we have named schema.edn. I could execute post and get graphql requests to get normal json response. But with the graph-i-ql, its a challenge, and even if I manage to read and run it somehow, am not sure how the queryroot will pick it up so that autocomplete suggestions and doc explorer works fine...

okwori17:03:22

Do you have any online repo project you can share maybe?

eggsyntax17:03:20

The one I've got is probably already too big to be of use, plus I'm doing a bunch of funky stuff with auto-generating the schema (& sample data) from specs. But graph-i-ql should already be working if you're starting from luminus +graphql. What happens if you go to in your browser and open the docs explorer? Do you get an error? If so, what?

eggsyntax17:03:36

The two ends of the built-in graphiql setup (in luminus +graphql) are: Server: the /api service route defined in routes/services.clj Client: the graphQLFetcher function in resources/templates/graphiql.html.

eggsyntax17:03:52

The request structure seems odd to me, which is something to be aware of -- it's using a top-level :graphql-query key on the request, rather than putting it in params or body (which is what I'd expect on a POST).

eggsyntax17:03:33

[EDIT - posted cljs fn but I think it's still broken, so deleting]

okwori17:03:20

When I visited localhost:3000/graphiql, I got the window alright... but Doc explorer is indicating NO SCHEMA AVAILABLE

eggsyntax17:03:14

Sounds like probably an issue with your schema. If you checkout the original version that was produced by the template, it should be working -- maybe just step forward from there or git bisect to find the change that broke it?

eggsyntax17:03:30

Just in case you haven't, you may have to restart the project or something to make sure your schema gets recompiled with the changes you've made. FWIW, here's my schema:

eggsyntax17:03:35

{:queries
 {:company_by_id
  {:type :Company,
   :args {:id {:type Int}},
   :resolve :query/company-by-id},
  :company_by_name
  {:type :Company,
   :args {:name {:type String}},
   :resolve :query/company-by-name},
  :company_by_group_name
  {:type :Company,
   :args {:group_name {:type String}},
   :resolve :query/company-by-group-name}},
 :objects
 {:Module {:fields {:id {:type ID}, :name {:type String}}},
  :Email {:fields {:id {:type ID}, :addresses {:type (list :String)}}},
  :Filter {:fields {:id {:type ID}, :name {:type String}}},
  :Location {:fields {:id {:type ID}, :name {:type String}}},
  :Company
  {:fields
   {:id {:type ID},
    :name {:type String},
    :group_name {:type String},
    :alias {:type :Email},
    :locations {:type (list :Location)},
    :modules {:type (list :Module)}}}}}

eggsyntax18:03:43

I've got to run for a few hours. It may be too much unrelated stuff to wade through, but just in case it would be helpful, here's my project in its current state (complete w/ git history): http://home.novonon.com/shortterm/infusion.zip

eggsyntax18:03:05

Good luck! I may be able to check back in later in case you have other qs I can answer.

eggsyntax19:03:52

OK, back for a bit. Looks like you graphiql (at least the luminus implementation) ALSO puts the query in the body, and it looks like that's the one that counts. Not sure why it also makes it a top-level key of the request. But I'm not that knowledgeable about http request/response stuff, maybe there's a good reason 🤷

eggsyntax19:03:33

Huh. I guess it just puts it in the body, and then (as an artifact of cljs-ajax?) it's available as a top-level key/val on the request.

eggsyntax19:03:50

Oh, I see, it's a piece of middleware that my colleague added that slurps the body and assoc-es it onto the request. So that's specific to my project.

eggsyntax19:03:17

Nope, sorry, my mistake again -- that's there in the template:

(defn wrap-graphql
  "If the request body contains an InputStream, reads the query, parses the json,
  and puts the resultant map into the request under the key :graphql-query."
  [handler]
  (fn [{:keys [body] :as req}]
    (let [data (cond
                 (instance? BytesInputStream body) (slurp body)
                 (string? body) body
                 :else nil)]
      (if data
        (handler (assoc req :graphql-query data))
        (handler req)))))

eggsyntax19:03:32

Anyway, hope I'm not confusing you more than I'm helping 😉

okwori14:03:12

Thanks for the detailed explanation... I managed to use the weekend to hack around your project...

okwori14:03:24

And I discovered that the +swagger conflicts with +graphql with the earlier superseding...

okwori14:03:27

Would be nice to have them run side by side though, I don't know if that's a good option for the template @U050CBXUZ

okwori14:03:19

I have a sample project: https://github.com/Okwori/graphqltest. The main advantage might be ease to run graphql query over rest client and ofc also via the graphiql. I could raise a pr if...

yogthos15:03:00

Ah yeah I think that should be pretty easy to fix

yogthos15:03:14

A pr would be most welcome :-)

yogthos13:03:03

there's a +graphql profile that includes Lacinia, I haven't looked at the docs explorer though

okwori13:03:15

Yes I did use it, but am still trying to see if I could get graphiql query browser(that comes inbuilt from the profile) to route and execute query like this: https://github.com/walmartlabs/lacinia-pedestal

okwori13:03:36

Here this is the closest I have seen: https://github.com/cnirrad/lacinia-test

okwori13:03:23

But still issues using the GraphiQL... will be nice to run this way https://rusty-leopard.herokuapp.com/index.html

gklijs14:03:01

Barry Allen is a great speaker 😉

yogthos18:03:58

ah I see, I haven't had a chance to do anything serious with graphql yet myself

yogthos18:03:19

if you get it working the way you want I'd be happy to help make a pr for the profile

eggsyntax14:03:01

Hey @simon I've recently started a new project with luminus +graphql. Graph/i/QL is working out of the box, including the docs explorer (although it took me a while to figure it all out, including the existence of the graph/i/ql component 😉 ). I'm not sure from what you said whether you're wanting to actually use lacinia-pedestal, or you're just using it as an example -- my (offhand) impression was that it made sense to pick either l-p or luminus +graphql, that they wouldn't necessarily play well together. If you want to describe what's happening when you try to use the docs explorer, I'm happy to see if I recognize the problem.