Kick Start a JavaScript GraphQL API with Apollo-Server, Dataloader and Knex(bamtech.gitbooks.io)
bamtech.gitbooks.io
Kick Start a JavaScript GraphQL API with Apollo-Server, Dataloader and Knex
https://bamtech.gitbooks.io/dev-standards/content/backend/graphql-js/getting-started-with-apollo-server-dataloader-knex.mo.html
15 comments
GraphQL adds:
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.
* living documentation
* much better approach to versioning/deprecation
* type system
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.
This may be controversial, but I don't think REST is significantly simpler when implemented in a real project.
The setup for GraphQL takes longer than for REST because the ecosystem is still much younger, meaning you have to write some abstractions and helpers yourself. Once that's done, however, adding new types and new actions/mutations is about as hard in each and takes roughly the same amount of code. However, in GraphQL the maintenance cost from "hey, can you add X to the Y endpoint?" is dramatically reduced, and Apollo can save you from a lot of bugs by validating queries against the schema at compile time.
The setup for GraphQL takes longer than for REST because the ecosystem is still much younger, meaning you have to write some abstractions and helpers yourself. Once that's done, however, adding new types and new actions/mutations is about as hard in each and takes roughly the same amount of code. However, in GraphQL the maintenance cost from "hey, can you add X to the Y endpoint?" is dramatically reduced, and Apollo can save you from a lot of bugs by validating queries against the schema at compile time.
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
[1] - https://github.com/graphql/graphql-js/blob/master/PATENTS
No, you're looking at the reference graphql server. Graphql itself (which is just a spec) is licensed under vanilla MIT.
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.
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.
how does oData hold against https://www.google.com/patents/US9646028 ? specifically the 'social networking' part?
(related: https://medium.com/@dwalsh.sdlr/using-graphql-why-facebook-n...)
[deleted]
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.
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
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.
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?
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.
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.
Are WebComponents a thing yet? It might be better to stick to the standards and polyfills at this point.
Striking the middle ground there is also postgrest[0] and their queryable REST approach.
[0] https://postgrest.com/en/v4.1/