
Kick Start a JavaScript GraphQL API with Apollo-Server, Dataloader and Knex - tpucci
https://bamtech.gitbooks.io/dev-standards/content/backend/graphql-js/getting-started-with-apollo-server-dataloader-knex.mo.html
======
HugoDaniel
I can see the niche that GraphQL tries to fit in. But seriouslly, REST is much
simpler and good enough for the huge majority of use cases.

Striking the middle ground there is also postgrest[0] and their queryable REST
approach.

[0] [https://postgrest.com/en/v4.1/](https://postgrest.com/en/v4.1/)

~~~
adamors
GraphQL adds:

    
    
      * living documentation
      * much better approach to versioning/deprecation
      * type system
    

etc.

For REST based APIs you have to figure out all of these (and usually they are
completely different accross projects/languages etc.).

Solutions like Swagger offer some sort of solution but they are still a PIA to
work with.

------
Mayzie
It should be noted that GraphQL is covered by the same BSD + Patents licence
as React.js and others. [1]

[1] - [https://github.com/graphql/graphql-
js/blob/master/PATENTS](https://github.com/graphql/graphql-
js/blob/master/PATENTS)

~~~
u320
No, you're looking at the reference graphql server. Graphql itself (which is
just a spec) is licensed under vanilla MIT.

~~~
skrebbel
That's funny, because while you can't patent code, you certainly can patent
ideas (such as the general principles behind graphql).

Let's assume Facebook has patents on the ideas behind GraphQL. I don't know
whether they do (and in all honesty I can't be bothered to find out, because
patents are written by misanthropes).

This means that if you use GraphQL but not any Facebook-provided source, they
_don 't_ promise to not use these against you. They could sue you into
oblivion any time, for any reason. But if you do use Facebook code, then you
got a patent grant, so you're good. Until you sue Facebook for infringing on
your own patents of course - in that case, you're back to the situation where
you used non-Facebook GraphQL implementations. 1)

That said, I think this is all void in reality, given that very little about
the ideas behind GraphQL is new (eg check out Microsoft's OData - nearly the
same thing except done by people who tuck their shirts into their jeans
instead of people with hoodies and hairdos). You'd probably be able to prove
prior art.

1) The same thing holds about React btw. I'm pretty convinced that any patent
that could cover React also covers Preact and Inferno. If they have such a
patent, they can use it against you any time. Except if you use React! In that
case, you got a patent grant and they can only use it against you once you sue
them first. So if you're worried about patents and think Facebook might grow a
patent troll department (hey, who knows), using React is safer than Preact or
any other pretty-close React clone.

~~~
devdoomari
how does oData hold against
[https://www.google.com/patents/US9646028](https://www.google.com/patents/US9646028)
? specifically the 'social networking' part? (related:
[https://medium.com/@dwalsh.sdlr/using-graphql-why-
facebook-n...](https://medium.com/@dwalsh.sdlr/using-graphql-why-facebook-now-
owns-you-3182751028c9))

------
bradmwalker
An undersold benefit of GraphQL is minimizing JavaScript footprint on domain
logic. This can be hidden in the API by precomputing many things, and client-
side logic can be reduced to presentation and event handling. Hand-rolled data
munging and client-side caching are n't necessary, and there's a clean
separation between the browser and the backed.

------
vanwalj
Nice tutorial, just not found of the authorization part, which "encourage" you
to rely on http headers. Imho http headers are fine for a REST API, since the
protocol depend on HTTP, but not for a GraphQL API since you can perfectly
serve GraphQL behind something else, like Websocket, nats, or even direct TCP

~~~
tpucci
Thank you for your comment. You are right and I admit I didn't come with
another solution at this time. This is why I did not write a huge part about
authorizations.

------
yodsanklai
It's amazing the number of software and APIs related to javascript that people
are interested in. GraphQL, Apollo-Server, Dataloader, Knex... any advice on
where I should start to get some familiarity with the javascript ecosystem?

~~~
phatbyte
At this point, I really can no longer give anyone an advice. JS
frameworks/libs/concepts come as fast as they go, it's hard keep up. Eg: Last
week React was awesome and the defacto framework to learn, but then to the
it's license I see a lot of people moving away from it.

~~~
my_ghola
But what is people fleeing to? The other 2 notorious frameworks are Angular
and Vue.js. I've never tried Vue.js but Angular seems to come with a higher
complexity than React. I know of Inferno.js which is very similar to React but
comes with an MIT license, however the author was hired by Facebook so who
knows how long it will stand.

Are WebComponents a thing yet? It might be better to stick to the standards
and polyfills at this point.

