Description
Key Learnings
- See how GraphQL fits with the Autodesk Platform Services Data initiatives.
- Learn about the latest Autodesk Forma, Autodesk Fusion, and Autodesk Flow data initiatives, and how to access your design data with GraphQL.
- See the Data Exchange API work across the data models.
Speaker
- Kevin VandecarKevin Vandecar is a Developer Advocate Engineer and also the manager for the Autodesk Platform Services Media & Entertainment and Manufacturing Workgroups. His specialty is 3ds Max software customization and programming areas, including the Autodesk Platform Services Design Automation for 3ds Max service. Most recently he has been working with the Autodesk Platform Services Data initiatives, including Data Exchange API and Fusion Data API.
KEVIN VANDECAR: Hello, everyone. My name is Kevin Vandecar, and we're here to talk about accessing granular design data using our new GraphQL that's based in the Autodesk Platform Services. My team is a team of developer advocates. We support many of the desktop APIs in the M&E and in the manufacturing space, and then we support all of the Autodesk Platform Services APIs.
So to start, I just want to point out the safe harbor statement. You've probably seen this a bunch of times, but the point here is that a lot of this technology is actually in a beta phase right now. So just want to make sure you're not making business or purchasing decisions based on beta technology.
So here is our agenda for today. We're going to do just a brief overview of the Autodesk data models. We'll talk about why we chose GraphQL, and then, we'll go into the details of GraphQL with syntax and data, and we'll wrap up with a list of resources. So first of all, let's get started with the data models with some background.
So our goal, our vision, is a fileless future. So when you think about your workflows today, everything is file-based. So you have a Revit design, it's a file. And it's just really important to think about that file becoming data and what that means. So no more having to move files around and deal with that container where it can get corrupted, it can be copied and you lose versioning information, multiple versions of the files spread across your network, and so forth. We envision a fileless future. So it's not going to go away immediately, but this is the goal.
So what does that mean, moving from files and folders on a disk to manage models and assets in a project? Taking naming conventions and file paths and all that storage muck and moving to real data with structure, relationships, and versions. Scripts, your local tribal knowledge, things that you do with your pipeline, your workflows, we want those to be well defined software workflows.
And by providing these really nice and granular APIs gives you a lot more specificity to be able to get the data that you need. And doing away with these data silos and special files that you have to manage and moving to a real information model.
So when this comes down to granular data, so in this graphic, you'll see the file on the left, and whatever is in that file, we want to explode that out into individual bits of data. And that data will be stored in the cloud, and that's the philosophy behind the data models in general and where the granular data concept comes from.
So to take a look at the vision overall, we have this graphic where Autodesk Platform Services is at the bottom, we have the Autodesk data model built on Platform Services, and then, the three industry models on top of that. So what this shows is that everything is based on Platform Services, and at the data model level, we have a common graph structure. So it's a graph database that each of the industry models are built upon.
And the authoring of these data models is going to come from Autodesk products, but also could come from other products with custom data. So manufacturing is obviously Fusion and eventually Inventor. We've got the data model, which is Revit today, but you'll be seeing things like AutoCAD coming into the mix. And then, the media and entertainment data model is now being developed. And so we haven't gotten to the point of doing any public exposure yet, but it's underway.
And what all this does is, basically, allows you as a customer, you as a partner, you as a third party developer, even, to access this data. So multiple ways and using permissions and things like that to allow you to share the data with those that you want.
And this all comes down to the three industry models. And then, I also want to mention Data Exchange because we're going to be using that a lot today for some of our demonstrations. Data Exchange sits between the data models and it is a way to provide interop and sharing of data between those data models.
So GraphQL to the rescue. Why did we choose GraphQL? So Design and Make data in the hands of our customers is the most important aspect here. We chose GraphQL because it delivers on the granular data promise, and it reveals product agnostic graph data models and data itself.
So when you think about the why do we even have three different industry models, well, each industry has different types of data that it needs to work with, and that's where this product agnostic aspect comes in where the underlying structure is the same. The GraphQL syntax is the same. It's just the industry data that's different depending on each model.
So again, to summarize, this is delivering the promise of granular Design and Make data, bringing the Design and Make platform data into the hands of our customers and partners, and for data models all sharing similar data access through this GraphQL. And the only requirement is to understand your industry data, it's easy to learn and code, and it's immediately accessible and granular.
And when I talk about bringing it into the hands of our customers and partners, traditionally, APIs are not as easy to use from a customer persona. So if you're a Revit architect and you're using Revit on a daily basis, you may consider yourself a power user. And even that persona is what we think is going to benefit from these GraphQL APIs because it's very easy. It's very similar to using a query language and allows you from power user all the way down to super sophisticated deep developer to access the data in the same way.
So what is GraphQL exactly? So it is a query language for the API. It provides a complete and understandable description of the data via the API. It gives you the power to ask for exactly what you need and nothing more. And this is an important point here is that, instead of REST API where you get pretty much all or nothing, the GraphQL allows you to ask for very specific pieces of data.
This is an open-source project from Meta, which is the parent company of Facebook. It was designed for Facebook. And they've open sourced this project, which is awesome because the industry is now moving to it to create industry standard ways of accessing data as well. So let's take a look at a quick demonstration.
The very first thing we're going to do here is show the promise of granular data. So GraphQL allows you to very specifically ask for the things that you want to know about. So the first thing we're going to do is we're just going to drill down into Data Exchange and get the furniture details.
So this is a big long list, very similar to Model Derivative, it's still limited to just the furniture. And from Data Exchange perspective, this is the view of the exchange and this is all the data that's there. So it's a very small set of data to begin with, and that's the power of Data Exchange. But in general, the data models have all the data from the design in their data model representation.
So I executed this, and there's quite a bit of data here to filter through and a lot of extra information that maybe I don't need. So let's look at the granular aspect. So it's the same query, essentially, so we got furniture details. But what we're passing in here is we want the latest version of the model and we're getting everything.
When we switch over here, what we've done is we've filtered out a lot of detail. So the query itself is saying, I want the objects that have property name, type equal to seating Artemus lounge chairs. When we go back over here, that's the Artemis lounge chairs. So there should be two of them. There's two of them in this model. They have different names because there are different instances, but there's two of them there.
So let's go back and we're going to execute the get chairs query. So basically, asking for the same information, except we're filtering now by type and name for the output and we're querying for the specific element name. So we'll execute that. Bang. Two entries, very simple data. So we can confirm that, yes, it found it, but we don't even need that once we trust the data.
There's the name of the instances that would be represented in the model. And so we can quickly see, well, how many of those Artemis chairs do we have to order. They're expensive, so we want to do some cost analysis or whatever and we can find it immediately. Very powerful.
OK, so the next section here is to talk about the syntax and the data itself and how you access it. So first thing I want to point out is that GraphQL provides these pure queries, and this is the manufacturing data model example. And I want to just show how it's really also connected to the authoring of the data. So on the left, you'll see the query engine, and on the right, you see the user interface from Fusion. And you can see how the data is aligned with the output of the query. So very nice, even from a user perspective, to understand how your data is organized and structured.
So let's also talk about GraphQL versus REST. We get that question a lot. Why did we switch to GraphQL? And really, a lot of this is about performance and granular access. So first of all, let's talk about performance. Many less calls. You can do multiple queries per call with the GraphQL side, and you get less unnecessary data as well.
So if we look at a quick example on the data management side, the data models are accessed in the same way you would access your files in ACC Docs, for example, or Infusion Teams. And so we still have the notion of hubs and projects and folders and so forth.
So in the REST API example, you would have to call the REST APIs multiple times. There's a hub's endpoint, there's a projects endpoint, and so forth to drill down and get those. And if you wanted multiple hubs at the same time, you would have to multiply the number of calls times 2 to get 2, for example, and that adds up really quickly. But in GraphQL, you can see the query on the right is showing a single query that is getting two hubs by name, and then, the data behind those hubs. So again, very powerful and more efficient.
OK, so let's dive into some of the syntax. So first of all, I want to point out that these screenshots in the next few slides come from a tool called GraphQL Voyager, and I will give a demo of that later on. But let's talk about syntax now.
So first of all, objects is the topped level, and we use objects because it's a very type system. That's what helps with the query mechanism to find specific things. So an object is made up of fields, and fields represent types of objects that are within that object itself. So in this example, element has properties, reference properties, elements, and so forth. And on the left, you can see the fields that you would use to query for those things.
So moving on to arguments. So arguments are very much like input to function. So if your programming already, you know how to handle this, and basically, you pass in arguments to be executed against. So the arguments will be passed separately through a variables block. So you can see arguments, in this example at the top, the query itself is taking a couple of arguments. And then, even within the structure of the query itself, more arguments are being passed, so a little different than a traditional programming language.
OK, moving on to aliases. Aliases help you to organize your data based on your own workflows and desires. So in this example, you'll see operation property is the Alias, and then, below that is volume property, another Alias. And when you look at the results, you'll see that Alias exists in the results as well.
And just one word about the results is that that field is an Autodesk-specific field. It's something that we use to organize the results logically in the output. So in this case, you're getting, essentially, three blocks of results. And using the Alias, you can label those two that are specified in the query.
And then, we also have fragments, and fragments you can think of as reusable blocks of query code. So in this example, we've taken those operation property and volume property and we've made a fragment that makes up the common properties that we want output, and that fragment is coded in one place and then it's reused simply by specifying it in this manner with the dots and the name of the fragment.
And then, directives are a way to dynamically change the structure and shape of your queries using variables. So in this example, we're using and if then else type block. So if the requested properties is false, we get one type of output. If it's true, we're going to get a different type of output. So it allows you to take the same query and direct it based on your input.
And finally, mutations are an important part of GraphQL. This is where you can change data. Now, not too many of our data model aspects have the ability to change yet, but I wanted to introduce this concept because, as we start maturing the data models, you will be able to change certain aspects of it by adding your own properties, your own custom properties, and so forth, and mutations will be the way that you execute those.
Also want to talk about schema and the data structure itself. So first of all, many people have used Model Derivative for a number of years. And in a sense, the data models will replace the need for translating files to get the data out of some of the mainstream products. So for example, Revit will write the data model directly. And when we compare that back to Model Derivative data, you look at Model Derivative and it's just a simple property value pair. There's no typing at all, and it's just a big giant list of everything in a single Revit file.
So when we start thinking about the data model, you can think of each one of those items as a property that has a definition, and so already much more structure. And here's a comparison. So again, typed data defined by a schema. And then, the next section here is, how do you learn about the data that's in the schema? So we have this tool that is another open source tool that's called GraphQL Voyager, and let me give you a demo of how that operates.
To start, one of the great tools we have at our disposal is called GraphQL Voyager. You, basically, can get to it by going to this website and its running instance. The beauty of this is that it is also an open source project. So just like GraphQL itself, the community, has put together some great tools, and the GraphQL Voyager is one of them.
So to use it, basically, you load it up and it starts with a default schema, just to give you an example. So we can Zoom in and it has zooming and panning capabilities. And the first thing you're going to notice is that here's one of our objects. We looked at this earlier in our syntax section. So here's an object. And within that object are fields. And these fields are things that you can query on.
And you'll also notice that the object has these references to other parts of the graph. So planet connection, we chase this over. And here, it connects to this planet object. So very nice way to look at schemas. Now, how does this help us with the Autodesk data models?
What we can do is we can come over here and we can say change schema. And you'll see here's the default ones, and there's this introspection tab at the top. So you'll click that. You'll click Copy Introspection. So this actually copies an introspection query to your copy buffer, your clipboard.
And what I'm going to do is I'm going to switch over to our Data Explorer for Data Exchange. So I've already logged in and I've already pasted that introspection query here, but let's just do it again to show that it is the one that I just copied.
And when you look at this introspection query, you can see it's got all the queries that we're used to, all the elements of a query that we're used to that we talked about earlier, including fragments. And when we get down here, you're going to see a lot of things around the type, kind, and name, and that's going to help us drill down and get all of the data that's available through the schema.
So we're in this, we're going to execute it now. And what you're going to see is this big packet of data. So this is, technically, the schema. And if you're happy looking at data in this way, it's all here. But note that it is a very long set of data. So this is where the GraphQL Voyager really shines. So I'm going to copy this, and I'm going to go back to the Voyager and I'll paste the results of that introspection query. And what it's going to do is refresh and model a new schema based on that input.
And here we have it. So let's zoom in on the beginning. So here, at the beginning, we have an object called query, and these are the things that you can query on. These are the fields, so hubs-- hub, hubs, project, projects, things like that. When we look at hub, for example, we can click it and it's going to move over and show me what the hub object actually has for fields. And hubs, there's the hubs. Let's go look at folder, for example, which is over here. So there's the folders' collection, and then, there's the folder and the data fields that are available there.
So here's the exchange itself. And as we continue scrolling to the right, we're going to see the actual element itself. And then, we start to get into properties and property definitions, so we can click that. This is what a property definition looks like and how a property references that. So all of this is helpful to just understand how the schema is structured so that you can make better, more informed queries.
Just a word about the GraphiQL explorers. We do have one for each of the current production data models, so Data Exchange, Manufacturing Data Model, and AEC Data Model all each have its own explorers. This Explorer is based on GraphiQL, which is another open source project, and it, basically, is a sandbox and an easy way for you to test. So like I said before, if you're a power user, all you have to do is log in and you have access to your own data. Let's see a demo of that.
So this is the GraphiQL Explorer. We have one for each data model. So a AEC Data Model is here. We have the Data Exchange Explorer and we have the Manufacturing Data Model Explorer. So I'm going to start with the AC one just to show some of the features here.
Basically, you do need to sign in. So I've already done that just because, as an Autodesk employee, there's quite a bit more authentication than just a customer would have. So I've logged in, and this is giving me access to the ACC Docs data. And when there's an AEC Data Model there that's been produced by ACC Docs workflow, you're going to have access to those hubs and that data.
So before we go into actually using the Explorer, I want to point out a couple of features here. So you can see we've branded it, first of all, just so it's very clear that this is our tool. Again, GraphiQL is an open-source project, so we've basically branded it, customized it, and pre-populated some of the basic queries that will get you started.
So just by loading it up, these are the default queries that you have access to. And the Data Management ones, Git Hubs, Git Projects, so forth are ones that you're going to need to be using in all three cases. So we go over to Data Exchange. You see there's a Git Hubs and Manufacturing-- there's a Git Hubs query.
All right, so back to the AEC Data Model Explorer. Also want to point out that Voyager, which I showed earlier, which is the tool for reviewing the schema, has a button here. And so rather than having to go through that process of executing the introspection query, taking the introspection results and pasting it in Voyager, I can just click it and it will do that for you.
So it makes learning a lot easier. You can just click Voyager and it's going to open up a new tab with the Voyager pre-populated, in this case, with the AEC schema. And again, I showed this earlier, but you can navigate through the schema as you want. And this is kind of really helpful when you're learning and trying to figure out what query fields you can use and what the types are, so I can click and navigate through those types.
So all of the explorers have that ability to go into Voyager. At the moment, the Data Exchange one doesn't have the button, but it's-- I showed how to do that and we're working on adding the button here just to make it consistent. So it's a convenience feature.
There's also the viewer. So when you get down into data, you can actually enable the viewer within this tool as well and visually look at the information that you've queried as well, so that's kind of a cool feature. So how does this work? Well, I'm going to start by executing a query and it's getting my hubs. So that's the first step.
OK, so let's look at some of the features of GraphiQL and how to execute queries. So you'll see these tabs across the top. And again, these are the prepopulated queries that are available to you. You can enter anything you want here, so you can expand the query as you want.
Want to point out that there is a Documentation tab and it is interactive, so you can click through and see various aspects of the schema and the documentation that goes with it.
There's also a history. So as you start executing things, you're going to have a history list here. So you can always go back to a query that you executed and see them. Now, that's something I want to point out here is that these-- this session is kind of browser-- that browser is session specific.
So it does cache the things that you add. So if I were to add a new query here and then reload it, it's going to keep that, but it keeps that as browser cache, not connected to your account. So just make sure as you're creating queries that you store the queries that you want to reuse and put those somewhere else, create maybe a text file with your queries, maybe a place within the code that you're going to be executing this to have the queries so that you can get them back at any time. Because if you refresh your browser cache, it's going to default back to the original state.
So there's a way that you can refetch the GraphQL schema, and then, there's the shortcuts dialog. So some of the actions have shortcuts. You can play with that. And then, there's also a settings dialog, which it's really just the theme. You can change it from light and dark. And again, you can clear the storage. So this is, basically, going to refresh that cache within this instance. So it's the same idea as refreshing your browser cache.
So we did execute this one. I'm going to move over to the Data Exchange Explorer and execute that against the hubs again. And then, basically, this is kind of set up down the line for a linear approach to how you would execute queries at the start anyway.
So I basically took the hub that I want to work with, which is-- sorry, it is this one here, so b.5d2. And I've pasted that here as an input argument to the get projects, and I've executed that. So now, which project do I actually want to work with? I can go here and copy that one. And then, I can go put the project ID here and execute that.
So again, let's take a look at the structure of the query. So here's your query statement. This is the function name and these are the arguments that are coming in. And just want to point out some of the things. I mentioned results, that is a concept of the Autodesk schema. So all of your results will be in a results block.
And you notice you can have nested results, which is fine. And the other thing is things like type name for when you're learning. Now, remember that type name is kind of a performance hit on your query. So in production, you probably don't need it anyway unless you're testing for type for some reason.
But only use it when it's absolutely necessary because it will impact your overall performance in a production app. But for learning, it's really helpful. So in this particular example, folders, for example, the results are here. And you can see each one of the folders that it found is a folder. And when we compare-- when we go over to the Voyager, that folder can be found pretty easy just by searching, and there's what the folder is.
And so, in the query system, folders have, basically, these fields that you can query on. Now, how do you know those fields? Well, the nice thing about this-- sorry, go over here-- is that when you type something in, it's going to show you in the context of where you are, so for folders, these are the fields that are available to you. So this is also nice. You just start typing anything and it's going to pop up this list of available query fields.
All right, so I've gotten back my list of folders, and this is the folder that I want to use for the next query. So I'm going to move over here and I'm going to paste it into the folder ID argument. So this is the variable folder ID. It's going to get passed in, again, as an argument to that query. And now, this is giving me back the folders, but also the exchanges within that folder.
Now, one thing I want to point out is you see this one has turned kind of a yellow orange, and that's a warning. So what happened here? So if you hover over it, you get the complete information. It says that alternative representations is deprecated and use the alternative identifiers instead. So I'm just going to copy that. And you'll see that that orange changes to blue as an accepted field again.
So just remember that we are in beta and there are some minor changes still going on, and so this is a way for us to tell you that things have changed. And so that deprecation message will help you during your learning and executing of queries to know what's going on. So we'll run it again. And of course, we get the same results. So you saw that it did execute. So even though it's marked deprecated, it hasn't been completely removed yet, and we suggest what to use instead.
So now I've gotten back my exchanges and I'm going to look for the one that I want to work with. So again, remember, we're working with Data Exchange. So everything that we did to this point is very common to all the data models. But now, we're getting down to the specific data type that the data model is representing, and in this case, it's Data Exchange. So now I'm going to execute something that's specific to the Data Exchange schema and the Data Exchange data structures.
So I want to use this folder. And I'm going to move over here to get exchange ID and input that and I'm going to execute that. So again, we see a couple of these things that have changed. So this is now version history, which makes more sense. So I can put that there just to correct it. I mean, it did execute. And then, there's our alternative representations again. So let's just fix that so it looks right. And of course, we can execute it again, and now we've got this.
Now, now we've got information about the exchange. And the first thing you're going to notice is that this is the type, it's an exchange, it has a unique identifier. But then, when we look down into it, you see version history here, so versions and results, and we have three different versions. So this shows the power of the data model. So you can get these basic snapshots and you can know even when they were created and, of course, what version they are.
So if you just wanted to check for versions, you could do this and it will tell you what the latest version is. And let's see, we come down here, and here are some file-based information, this is the file earn and the file version earn. And then, there's the IDs for each specific version. And you see, even each version has a unique identifier.
OK, so I just want to point out how the data matches what's actually in the user interface for these tools, the user aspect of this. So I've opened up ACC Docs, and you can see the Revit files are here. And then, the exchanges have this separate icon. So that's how you know they're exchanges.
And when we look at the data, when I looked at folder content, you can see I was looking for exchanges and all of those exchanges are listed here that are the same as listed here. Now, I opened up the furniture, and when we got the exchange information, we saw that there were three versions. And in the ACC Docs UI, you see the same thing. There's three versions, created, date, and time, and it matches this data here. So very one for one in the data aspect.
Now that we've gotten the exchange information back, let's look at what's in the exchange. And I'm going to switch over here to get quantity takeoff. And this is a default query. And when I execute that, it's not going to find, really, anything because this category doesn't match anything in my scene. So I'm, basically, looking for categories of Revit objects. So I know that most of what that exchange is furniture.
So when I execute this-- and this could be an even larger scene that's made up of a lot of other things as well. So by saying furniture, it's narrowing it down, and I can see all of the things that are in this. So results are going to give you, basically, the name, the value. The category type ID is furniture, which is what we're looking here, and so forth.
So here's the actual elements-- so this is the element name, this is the family name, so it's an Ottoman. There's the IFC GUID if you're interested in things like that. And again, you can filter out some of these things that you don't really want. I mean, this happens to be part of a property definition here. So if there's no property definition, notice that it's just going to be null. Here's one of those Artemis lounge chairs, and that's something that I made changes to and we can see later how we can check and see those changes.
So now, we've executed all of these default queries, but now let's do something even more interesting. So I'm going to create a new query here, and I've just got it in my paste buffer, I've written it previously. I still haven't updated, so I'm just going to fix that so it looks right.
And the variables that I need to pass in, again, are the exchange ID. And I'm going to look for version information. So I can use this Alias called latest to get the last one, make sure I'm getting the latest one. And I'm going to look for these dining chairs, so specifically.
And you see, this is an element filter has this query tag that gets passed and it's used here. So this is one of those arguments that's part of a sub portion of the query. So go ahead and execute that. And now, you can see that it's only given me back information about those dining chairs and all the data associated with each one of those. And that's all defined by what I'm asking for as results.
So there is a lot of extra information here that maybe we don't want. And so, I wanted to start with more robust query, but let's say we really don't need the definition, for example. So this is what we mean by granular data. You can get just what you want. So here we go with just the name and value pair. And maybe we don't even want any of the properties associated with each one of these objects. So I can even take that away and all I'm going to get now is the ID and the name.
And again, because I'm looking for these dining chairs, these are the dining chairs. 1, 2, 3, 4, 5, 6, 7, 8 dining chairs. So pretty cool getting exactly what you want. So we've seen how to get specific details now. So I'm going to go ahead and create one more query here that will enable me to look at the differences between versions. So let me just enter these values here.
Now, one thing to note is we still need, of course, the exchange ID. And then, here's the filter input and the query, actually, has a range here. So from ID to ID, we're going to compare from the latest minus 1, which would be the previous version, and we're going to compare that to the latest version.
And I also want to just point out that pagination is something that you'll have to think about when there's a lot of data. So added this just as an example. We'll go ahead and execute this. And while we're talking about pagination, you'll see we've actually included that here, and it comes back with the page size for this. So I had a limit of 30, but I only got 8, so that's fine.
Now, this also helps you know how many things actually changed between these versions because we got eight records back. So you can get a number of changes just by using that trick. So let's look at what changed. So I'm going to scroll down and there's a wardrobe. And if you remember in the sample, there were two wardrobes on the second floor. And in the latest version of that-- so if we go over here and look, this is the latest version-- the wardrobes are not present. So let me just show you version two.
And you see, these are the wardrobes. So those are gone now. And let's go back over here. And so we know that a wardrobe-- the wardrobes have been removed, but how do we know that here. So first of all, here's the item that's actually up here in the name, so this is the wardrobe, and all of the data associated with it. But at the very end of the data set is an operation.
And this value says remove. So we know that this data, this item that was in the scene, has been removed from the latest scene as compared to the prior version. So it gives us very specific information. And operations can include inserted. And then, there is also a modify, which will point out things that have been changed somehow. And in this case, they were moved around. So we're getting back very clean, clear data about what changed or differences between two versions.
We're going to take a quick look at the Manufacturing Data Model Explorer just to show that all the data models work very much the same, use the same GraphQL syntax, and same approach to getting your granular data back. With the Manufacturing Data Model, we have two versions. So I want you to pay attention to that right out of the gate. Really suggest that you use version two, which is technically still in beta as of this recording, but we'll be going into general availability very soon.
So switch to V2 and then you're going to get these pre-populated queries for the V2 API. And then, like with Data Exchange and with AEC Data Model, we need to go through hubs, projects, contents of the project folders, all the typical data management type activities.
So I'm going to jump over to Git model hierarchy and, basically, just have a query that I took from the sample code, from the documentation, and I've executed this. And I just want to show just like with Data Exchange and AEC Data Model, the data structure is very much the same as you would see in the product itself. So if we look at the Autodesk Fusion Teams and we look at the model, here's the browser, this would look very similar in Fusion itself. This is the model I'm looking at.
So if we come back over here, you can see that's the name of the model. Two-ton twotonjack_2-kdv. And it has all of the components as you would see them listed here. And it also has the hierarchy. So if there were nested elements in an assembly, for example, you're going to see all of that data in this data structure. So that's why there's a parent, component version, and a component version, and the names, of course, for being able to recognize everything.
So that's the demo for the GraphiQL Explorers. So just want to point out some other tools. You can use other industry standard tools for executing your GraphQL queries. A lot of people are used to Postman or Insomnia for REST API type calls, and they both support GraphQL. There's also a tool called Apollo Studio, and that's a more advanced GraphQL tool designed specially for GraphQL. And it's a commercial tool, so it does cost some money. But they even have a plugin for Visual Studio code.
And then, I just did a quick search inside of the marketplace and you can see that there's a whole bunch of other independent GraphQL tools out there. And so just to give you a quick demo of how that operates.
So let's talk about third party tools. As I mentioned in the previous slide, you can use any tool that supports GraphQL as you want. I'm going to show Postman as an example, Insomnia and the other tools work the same. The only difference is how they're lay out is and so forth.
So for example, I can execute the introspection. This is giving us back our schema. We could paste this into the Voyager, as we did before, so it's the same response here. Data management, basically, same thing. Send the query for githubs. It's giving me back my hubs. I can go ahead and select one of these things. I'm going to copy that and move to the next step.
So I'm going to list the projects next. So I'm going to, basically, hard code this, but this could be a Postman variable, for example, and we can execute that. So very similar to the REST API workflow that you may be used to when using REST APIs, and especially, Autodesk Platform Services REST APIs. You can do the same kind of learning and exploration and development of your queries using these external tools that you're already used to using.
So the last piece here is how do you actually code it. So our samples are generally based on Node.js and JavaScript, but .net samples are just as easy. It's not much different than a restapi.net sample. So let's take a quick look at how to code this.
Now, I want to talk about how to code these GraphQL queries. So the great news here is that any environment that you already use that supports REST APIs can call GraphQL. And the reason for that is because fundamentally under the covers is a REST endpoint. So each one of these data models have a GraphQL query endpoint that's in the REST API format.
So here's the Manufacturing Data Model endpoint, and here is the AEC Data Model endpoint, and here is the Data Exchange Data Model endpoint. So each one has its own. And then, when you come to the Docs, you're going to see specific samples for each one. And there's a GitHub repository for each one as well.
And when you click down into this code, you're going to find the queries themselves. So I just clicked into the app.js and here you go. You can see there's a function in JavaScript that is typical Git project ID, and you pass in parameters like you would with JavaScript.
But the query itself is laid out here in text with the input objects, just as we saw from the GraphiQL Explorer perspective. So very easy to take your learning and actually bring it into code that you can execute in your existing code base or building new web apps.
And finally, just want to list out the resources for you to get started. This will all be included in the handout that's associated with the class. And so you'll be able to take a look at that and get yourself jump started. And just want to thank you so much for taking this class and paying attention to what we've got here with the data models, and thank you so much.
Downloads
Tags
Product | |
Industries | |
Topics |