Fork me on GitHub
#graphql
<
2018-07-05
>
souenzzo01:07:38

graphql is a specification about "how to exchange data between client and server" lacinia implements graphql in clojure, the server part (on client you can use JS or any other stuff. There is no good/easy cljs graphql client) walkable is a experimental way to query a SQL. pathom is a cool way to to implement a "parser", the server side of #fulcro/#om .next that do "almost the same thing" that lacinia does (pathom do more and do not implement a graphql server) datascript is a way to store/query data in cljs or clj. you can use it to store the state of a webapp. All this tecnologies has one thing in common: they all query data as a graph.

👍 4
gklijs03:07:10

I don't agree with you that there are no good/easy cljs graphql clients. I used https://github.com/oliyh/re-graph which was both easy to use and good.

☝️ 4
👍 4
souenzzo11:07:17

Sorry 😅 But there is something that help us to generate de query, given a collection of components?

gklijs14:07:38

That was noet there I think, but it’s pretty easy from GraphIQl to get the query you want, and it’s easy to have some variables in there.

👍 4
kwladyka06:07:03

thank you, it clears for me a few things.

kwladyka06:07:32

How would you compare lacina vs walkable (pathom) in the context of API and general purpose?

myguidingstar07:07:47

lacina and pathom serves the same purpose (walkable is just a pathom plugin)

kwladyka07:07:08

As I understand datascript query (not datascript itself) doesn’t have this possibility to integrate with other types of database. In the same time I am confuse, because what I know datomic use almost the same queries and can be integrated with for example SQL. Am I right?

gklijs07:07:31

@kwladyka There is not really a relation between GraphQL and some database. GraphQL is just a format to do query/mutate calls. In the backend this could be linked to a database, but it might as well just be an in memory structure, or using rest calls for example to get the response.

kwladyka07:07:45

Can EDN queries (like datascript) be used in the same way?

myguidingstar07:07:26

you can place Lacina or Pathom in front of Datascript

kwladyka07:07:51

I mean: why not EDN queries to for example PostgreSQL?

kwladyka07:07:08

*EDN queries - like datascript queries

myguidingstar07:07:54

@kwladyka actually there are two things about "datascript queries"

myguidingstar07:07:12

1. pull syntax 2. datalog relations

myguidingstar07:07:18

1. pull syntax is the a list of attributes you want from an entities. This thing is not specific to any kind of database

kwladyka07:07:39

so while graphql can be used to get data from DB instead of REST API, why not this edn queries? What make graphql better?

myguidingstar08:07:04

of course you can do that with "edn queries" and pathom is the library for exactly that

kwladyka08:07:43

oh now i see

myguidingstar08:07:47

graphql is popular, hence the ecosystem

kwladyka08:07:18

so when use lacina vs pathom? pros and cons

myguidingstar08:07:54

if your team is all Clojure, then pathom is a good choice

myguidingstar08:07:17

if, for instance, your mobile team swear they'll never use Clojurescript, then you should stick to graphql (which means lacina in Clojure world)

kwladyka08:07:50

oh I don’t know too much about developing mobile app. I guess cljs is rare for that purpose. Am I right?

kwladyka08:07:05

can it be used with SWIFT?

myguidingstar08:07:05

not with swift, I think

myguidingstar08:07:57

not just mobile app, but single page web app as well

kwladyka08:07:30

SPA works pretty good in cljs IMO. But I understand the issue about multi tech team

kwladyka08:07:00

just I can imagine with mobile apps it can be more problematic, than with SPA

kwladyka08:07:30

but maybe because I am not mobile app dev

kwladyka08:07:00

thank you for explanation

kwladyka08:07:01

@myguidingstar besides of pathom is only for Clojure, graphql is more wide. Do you see pros/cons of solution itself? Simple vs complex, easy vs hard etc.?

myguidingstar08:07:35

@kwladyka Pathom is not popular even Clojure community 😄 the pros and cons can be found in this discussionshttps://www.reddit.com/r/Clojure/comments/8pvneh/beyond_graphql/

myguidingstar08:07:29

regarding the question simple vs complex, I don't have an answer, but one thing comes to mind: with graphql, you stick to some kind of type system, with pathom, you're more free, for better or worse 😄

myguidingstar08:07:05

with pathom you can use qualified keywords. These beasts make your code expressive and avoid naming conflicts in many cases

kwladyka08:07:59

I guess I have to use both to make an opinion 🙂

kwladyka08:07:02

but this low popularity even in Clojure makes me distanced

kwladyka08:07:53

but using edn is tempting 🙂

😂 4
kwladyka09:07:35

after all I have this conclusion: I want to have solution which let me public my API for developers. As I understand pathom is only for clj/cljs. We were talking about if team want work only in clj/cljs, but it is actually not only about team. It is about team and third party developers who want use API. Just in general context. So learning and use 2 solutions is more complex, than using 1.

kwladyka09:07:46

So in that conclusion graphql win

kwladyka09:07:52

only good cljs library is needed

kwladyka09:07:31

*good - queries as edn data, not string

kwladyka09:07:05

*somebody mentioned about re-graph, but there is string as query

troglotit10:07:40

there are libraries to generate string: https://github.com/district0x/graphql-query https://github.com/Vincit/venia https://github.com/retro/graphql-builder - the last one is not exactly about string generation, but some utilities for client

👍 4
blance16:07:39

Just found out that facebook has released a new specification for graphql last month, which includes some breaking changes. wondering if there Is any plan for lacinia to support the new spec in the future?

hlship19:07:20

Lacinia is used in production but still alpha; we try to avoid major breaking changes, but we've made small incompatible changes in the occasional odd corner. I think we should embrace the changes in the lastest version of the spec; it'll be some work for us (both in Lacinia and in our production apps) to deal with the changes to the returned error maps.

blance22:07:15

glad to know that, and thanks for the good works:+1: