Last week I wrote about Autodesk Forge. Forge is a part of our technology stack at Lagarsoft that makes us unique compared to many other software consultants. To recap, Forge is a set of APIs that enable you to create programs using design and engineering data or pull that data into other systems so you don't need a program like Revit to open them up.
Today I want to talk about APIs a little bit further. I'm not going to write a full blog post today about APIs because we would really go down a deep rabbit hole. If you are unfamiliar with what an API is though, the main thing you need to know is that in programming, an API allows external access to data that is contained in a software program. That's a gross oversimplification, but it will have to do until I have time to dedicate a longer post.Even if you are unfamiliar with APIs, they are used everywhere. If you see weather information presented by Google, it's coming from a meteorological API. If you pay for something online via Paypal or another payment app, you are using their API to access information about your finances. If you login and click the "login with Google/Facebook/etc" option, again, you are using an API.
APIs can give you access to lots of information. If you play fantasy sports, you can pull huge datasets from sources like the NFL showing game by game stats or historical player performance. But how do you retrieve this information? Just like everything else in software, you need to know the right question to ask the system, that's a query language.
If you clicked on that link you'll notice it says "Rest API" which brings me to my next point. Rest is the query language, and refers to how the data is structured and requested. Over the last few years, Rest has become the de-facto standard for query language for APIs. The only problem is the data. There is lots of it, and using a Rest API means you will get all of it. If you need to pull from multiple sources, it gets even more complex. This is ok, but can cause some issues when there is alot of data on the server side of things or when you need information from multiple end points.
Think back to our sports example. Regardless of the sport, league, or any other variable you can imagine there is alot of data to be parsed through. Often in an example like creating performance dashboards for sports metrics you would simply use a drag and drop interface such as PowerBI or Tableau to present the data you need in the way you wish to consume it. This is a fine workaround, but what happens if you want to just look at a particular subset without the system needing a long time to update in an application? What if you are on a mobile device where you only have a certain amount of bandwidth? This is where GraphQL can make a developer's life much easier.
GraphQL was developed internally by Facebook in 2012 and became open source in 2015. Shortly thereafter it got its own open source foundation managed by the Linux foundation. Today it's used by some of the biggest names in tech including Facebook, Netflix, Shopify, and Twitter.
As I mentioned above, a key limitation to Rest APIs is the fact that the server supplies all data available. Rest APIs also pull data from multiple sources adding to the data bottlenect. This can create huge disadvantages as you retrieve large datasets. GraphQL in comparison lets you request only the data you need. If the query is written correctly you get only the data you requested.
If you want to learn more about GraphQL there are two great resources I would take a look at: