Jim Lynch Codes
  • Blog
  • About Jim

Writings about one coder's stories & experiences.

Thoughts On GraphQL Without Actually Really Using GraphQL

8/23/2019

0 Comments

 
Today at work someone presented on graphQL, and there was an interesting discussion among all the engineers in the room about it. There was been a few times where I have had the chance to learn about graphQL, and I feel like I often leave thinking, "hey, that's a cool" but then never actually start using it in my development. Welp, that has been somewhat of the case again. Lol

GraphQL is NOT a Graph Database

Ok, so the first thing that I really need to make clear right off the bat is that graphQL is NOT and kind of has nothing to do with graph databases. Graph databases are the things that Facebook, for example, uses to represent relationships between people. In mathematics a graph is a way of representing data that involves "nodes" and "edges". Graph databases such as Neo4j and OrientDb model data in terms of node-edge relationships, but graphQL is a completely different thing and can work with any old relational or noSql database.

It's For The Read in CRUD

The real power in graphQL is that it makes the "read" piece of your CRUD operations super flexible yet easy to build. Suppose for a minute that you have a postgres table full of data, and each row has 100 columns. Say you wanted to pull an object that had only a subset of the available properties, or possibly a few rows , each with only a row columns worth of data. With graphQL it's cake to do this because the way it is setup is that the consumer can specify exactly the shape of the object he or she wants. The api only has to know what is the largest possible object that can be returned (and so schema changes are usually additions of new fields), and it is quite easy when querying to ask for only specifically what you need.

Consolidating Requests

Another benefit of using graphQL is that it can consolidate your request logic so that the frontend sees it as one single request and response even though the graphQL layer could be calling to multiple endpoints, rearranging things, etc. We heard a story where this was especially useful to our ios team who could pull a lot of logic out of the front-end app which was tough to patch bugs and deploy and move this code over to the server side where it could be more easily and quickly deployed. Another good point to make here is that your graphQL server can be much more powerful than a user's device (think compared to a random cricket wireless cell phone), and it could be on the same VPN or at least hosted "closer" to your other endpoints / databases to which it may be communicating.

Great For Multiple Consumers Of An API Who All Need Different Properties of the Response Data

The query flexibility makes graphQL especially great for apis that have multiple consumers since in theory any should should be able to query anything he or she wants without the backend developers  having to write a special endpoint "/whatever" that returns these things, but not these other things, and some of those things... For these use cases graphQL can be a godsend and can really make what may have been tons and code before just given to you right out of the box!

Just One More Server!

Yep, graphQL normally runs on its own server. I haven't dove too deep into the code, but one of my colleagues said that you really just set up a modified express node.js script, and that's the graphQL endpoint! graphQL can work with other apis or connect directly onto a database (and it supports many different databases). 

XXX Dashboard

During the presentation there was a demo of the ___ dashboard. It is a pretty neat little SaS service that hooks into your graphQL
0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    ​Author

    Picture
    The posts on this site are written and maintained by Jim Lynch. About Jim...
    Follow @JimLynchCodes
    Follow @JimLynchCodes

    Categories

    All
    Actionscript 3
    Angular
    AngularJS
    Automated Testing
    AWS Lambda
    Behavior Driven Development
    Blockchain
    Blogging
    Business Building
    C#
    C / C++
    ClojureScript / Clojure
    Coding
    Community Service
    CS Philosophy
    Css / Scss
    Dev Ops
    Firebase
    Fitness
    Flash
    Front End
    Functional Programming
    Git
    Go Lang
    Haskell
    Illustrations
    Investing
    Java
    Javascript
    Lean
    Life
    Linux
    Logic Pro
    Music
    Node.js
    Planning
    Productivity
    Professionalism
    Python
    React
    Redux / Ngrx
    Refactoring
    Reusable Components
    Rust
    Security
    Serverless
    Shell Scripting
    Swift
    Test Driven Development
    Things
    TypeScript
    Useful Sites
    Useful Tools
    Video
    Website Development
    WebStorm
    Writing

    Archives

    August 2021
    February 2021
    January 2021
    October 2020
    September 2020
    May 2020
    April 2020
    February 2020
    January 2020
    December 2019
    October 2019
    September 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    May 2017
    April 2017
    March 2017
    February 2017
    January 2017
    December 2016
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015

    RSS Feed

  • Blog
  • About Jim
JimLynchCodes © 2021