Access Granular Design Data Using GraphQL in Autodesk Platform Services

AUGUSTO GONCALVES: Hello. Welcome to this presentation. This is how to access granular design data using GraphQL in the Autodesk platform services. My name is Augusto Goncalves. I'm a developer advocate manager here at Autodesk.

And this is a topic that is very interesting because we will be exploring a bit more on GraphQL and how that empowers you as a developer to use the Autodesk data that you have, all the data models that we are offering. So it's a very interesting topic.

We'll be covering a lot. And we'll be covering how to get started, where can you get the information, and also a lot on future stuff that we are going to-- we are still working on that. And because of that, we have a safe harbor statement because we may be showing some features and products that are not yet available.

So please make sure that we're not making any purchase decision based on that. So with that, let's get started. We are going to cover the Autodesk data models, some of the GraphQL ecosystem and syntax, how to use that, some tools, and how to use those tools to make better use of Autodesk data models and GraphQL.

Last, the Autodesk data model, which is something very new that we're working on that will be really powerful and help you access your data, and last, to get started, where you can get more information to get started, links, documentation, samples. All of that is available as part of the Autodesk platform services. And I'm going to show you some links and where to get that information.

All right. Let's go for it. And the first topic is the Autodesk data model. And it's really about GraphQL, how can you access our data with graph, and how is that really powerful for your data. To understand that, we have to think about this fileless future, where we don't have these big chunk files that we are flying around.

Think today that we have Revit file or AutoCAD file that is 1 gig, 10-gig models. That is always flying around, and we need that to access our data. So how can we move to a future where we don't have those files anymore? And how can we be more precise and more granular with the data that we have?

So the idea is to go from files that, as I said, are a very big force and required a lot of transformation to access the data. And they are slow because they are big. They are hard to open, hard to read, and sometimes they get very messy when you have versions.

We have version 1, 2, version 10, and that's getting very-- gets very, very complicated. So how can we now move from files to a more granular data, where the data that we want, which is very granular, we just access the part of the data that we want without needing to access all of that at once.

And that data is also interoperable because we can go from one format to the other because this data we can just convert to the format that we want and also accessible. And by accessible, it really means no being cloud-oriented, where we have any device that is connected to the cloud, we can then use to access the data that we want.

When we say granular, what do we mean by that? So today, if we think a Revit file is an example or a CAD file, inside that file, we have geometry information. We have manufacturing information. We have design information.

There's a lot of data there. So how can we split off the pieces inside that file and break that file into valuable pieces or bits of data? Then we can organize that data and store that data in the cloud in a very secure and controlled way.

And with that, we can allow people and also machines to collaborate efficiently on that data. So in this case, here we have people, systems, and processes connected to the data that is sitting in the cloud. And with that, we can give access just to the piece of data that we want.

So if we think about the various personas, maybe just want a render of my model, or sometimes I want the data to create a report, or I want fabrication instructions from my model. Depending on the user, we can have different access to it.

And it also needs to be simple to use. It needs to have granular APIs because it's not only Autodesk products accessing that data. We may have many other types of products and many other types of consumers using that data. That's where the cloud-accessible data comes into play.

So Autodesk, we are creating the Autodesk data models-- one for AEC, Architecture, Engineering, Construction, two more models for design and manufacturing, and another one for media and entertainment. The design and manufacturing data model is already available as part of Fusion.

It's a manufacturing data model, and the media and entertainment still coming. So it's still under development. We are converting those products to be what we know as Fusion, Forma, and Flow, which was announced by Autodesk a while back.

All of those data models are sitting on top of the Autodesk Platform Services, which is how you use the APIs to access the data we have on the data models. Now, each data model is actually designed as a graph. And the graph means that we have pieces of the data connected to each other in a more convenient way.

And if you think as a graph, it's pretty much like we organize our designs. Right? We have various pieces of information that are connected to each other. And we may have several connections to those several pieces.

Let's say we have this piece of a wall that is connected to a window, or we have this sketch that is connected to a extrude model. So all of those pieces of data are connected to each other in various ways. So let's say we have a CAD data. Like a house, right?

In this case, we can think the graph as the various pieces of our house. It can be as granular as the entire wall, the entire roof, or small pieces inside that wall or roof. Now, the data that comes to that house or to that model is very rich web of interrelated data that different people have different access.

Remember our original information, where we have the renderer, or we have the construction details, or we have report information, all of that coming in different pieces. And because that data is accessible, we can also-- [? inextensible, ?] sorry-- we can add more and more consumers and add more and more value to that data as we connect more and more pieces to it.

Because this is also a graph, we can do queries on this data. And the query uses GraphQL, which is the interesting piece about this technology, how we can use that as developers. So the query is easy to learn and more human-friendly because we are querying the pieces, and we can specify queries and all the data that we want.

So in this case, here we have GetAllWindows, where we say this is very hypothetical. But it's very close to what we actually have, where we have the elements, and then we do a filter to-- of [? type ?] windows. And we say that we just want the properties like width, height, and fire rating.

And as we specify the exact filter that we want and the exact data that we want to get out of it, it's very specific, and we know what kind of information we are getting. Because we are just making a very specific query, the data that we get is just the data that we asked for.

And because each industry has his own cloud, we can query specific pieces of data on each cloud. And all of those cloud datas will have their own GraphQL APIs, one for each of the data models. And because that data is part of GraphQL and accessible, we can exchange data between one and the other and in between each cloud, between customers or instances using data exchange, which is the API to exchange data between one cloud, one instance, and the next piece, and next consumer of that.

Those data models will be accessible through the products. Today, we already have Fusion. We are working to have also Revit. And the media and entertainment, the Flow, will come shortly. To use that, we have GraphQL. And there is a development ecosystem around that-- developer ecosystem around that.

So let's see what are the tools and what we can use to access that data in a more easier and convenient way. First, why GraphQL? Why we're choosing GraphQL instead of anything else, right? GraphQL is very good. We have a graph data, and GraphQL is very good to access that data and make that into the hands of our customers. That's the easiest way to access that data.

And it delivers on the promise of the granular data that we're making, right? We're accessing granular data. And GraphQL is a very easy and convenient way to get there. And because GraphQL is independent, it's agnostic. Right? It's not developed by Autodesk.

It's just the data that we want, and it hides all the complexity of the actual design data that we have behind. GraphQL, it's evolving. There is more industries and more companies using that. So there are common objects that are shared across different parts.

There are common units of measure inside Autodesk. So the first work that we did was to define how measures and units are defined in the system. So it's better interchangeable between the pieces.

And there are different patterns that we can use across different models because we are not making different data models, one for each. The different standards, they are all following the same basic definition. So it gets easier and easier for you to-- if you learn one, you can follow the same standard for the next one.

And there is not one single way of accessing the data. You don't have to have-- you don't need to access different endpoints. There is just one endpoint that you can get all the information, just one way to access data and the queries. You just define the query and can use that query.

So how can we use GraphQL? How can we do it? How come GraphQL is the rescue to access all of your graph information inside the data models? GraphQL is a language for the API that we use.

It provides a very, very complete and understandable description of the data in the API because we are specifying all that you want. Gives the power to access and ask exactly what we're looking for and nothing more.

Here on the sample that you see on the right, we specify the hero in this hypothetical sample. Right? We have hero name, height, and mass. But if we just say name, then it goes back to just the name. So the information we specify is the information that we are getting.

And it's easier to use than REST because there is just one endpoint. And when we call that, we specify the data that we want. So it's easier to call with GraphQL. And it's also an open-source project maintained by Meta for Facebook.

So it's not only Autodesk. There is a community behind it, and it's growing a lot. And it's more and more people using it. So there's a very bright future there. So let's see a demo on how we can use GraphQL.

So this first demo, it's using data exchange as a way to explain that. So in this case, I have-- data exchange is part of ACC. And we can exchange versions of the models. So in this case, I have a version one of my model. And I'm sharing one view of that.

And as you can see in this version one, I have lots of elements there. And I'm going to create a version four, which is a bit different. It has less elements in that exchange. Now, I'm getting way more deep in the code.

We have this query where we're getting the differences between versions in models. And what I'm getting here is the ID-- oops-- is the ID and name of the elements. And I also have elements in a pagination size. So I can specify how many pages I want on my query.

And for the results, I want to have the ID, the last modified date, the name, and the properties there has the operation that changed inside those elements. As you see on the top, we have this dollar sign exchange filter input. And we have some values that we are passing on, so variables.

And those variables are specified at the bottom. So I have the exchangeID, exchangeFilterInput, and elementPagination. That is coming as filters at the bottom. So now I'm going to run the query.

And as you can see here, we're getting all the elements that have changed between versions. And I see the name of the operation that was performed on that element from one version to the other. So I see here that the operation-- so this last element here, right? Was last modified on that date.

I have the name of the element-- W600, and I have the operation. And the value is modified. I see one on the top, where the operation is insert. Right? So I'm specifying exactly what I want, and I'm only getting the information that I want, nothing more.

OK. So let me-- let me just finalizing the video while explaing it. OK. Now let's see about how is the syntax for GraphQL with the data models.

So this first example here is showing the manufacturer model. And the information that I have on my model is coming from a design that was created in Fusion. And as you can see, you have the component version, the name. And that information that I have for a specific model is replicating the information from the tree.

And see the base modified is [? turning ?] base PCB. And there is a correlation between what I see on the data, of course, and what I see on the model because it's querying the same data. Fusion is storing the data in GraphQL.

Now, what we have with GraphQL in comparing to REST is that we have less calls. Essentially, we just do most-- most of the time will be one call. I have to do multiple calls if I have pagination. But comparing to REST, I don't have to make one query to get this piece of the data and another query to get another piece of the data. I can specify exactly what I want and get all of that at once.

Because GraphQL is giving me all the data at once, in the back end is running multiple queries to get that. So you can think that one query in GraphQL would represent several queries comparing to REST. And of course there is a performance cost there that we are working on to give you all the data that you want.

And because you can specify the data that you want, we don't get lots and lots of data. So the response body, the data that you get out is way less because we're not getting all that unnecessary data. So it's less data transferring to your system, especially if you have a very lightweight system like a mobile device. You don't want to get lots and lots of data, just get that small piece.

Now, here's another example comparing. And now it's getting more and more specific to Autodesk, right? On this sample. And we're comparing with the data management API. In this case, to get hubs and get all the projects in the hub, I would have to do one query to get all the hubs and then lots of queries to get all the projects on each hub.

But with GraphQL, I can just say give me all the hubs. And inside each hub, give me all the projects with the names of all of those projects, as you can see on the right. Right? So I have hubs, ID name, and then project name. So I'm just getting precise information that I want.

Now, I can also have multiple queries inside a single query in GraphQL, which is also saving me from doing multiple queries to the system. Right? So it's less latency. So in this case, I have a query with multiple filters.

So the first filter is a hub with name Fusion Data. And the second is a hub with name My Hub. So I can specify multiple filters, and then I will get multiple results out of that. With GraphQL, now compared with the model derivative API-- right? Because in model derivative we always get this value pair where we have the property name and the property value.

And this is interesting to compare because if you have a project today that is running with model derivative, you definitely want to do more experiments there and compare the data structure that you are getting out of GraphQL compared to model derivative.

And this is also important if we are missing any data. Let's say some of the data that you want is not available. So please be sure to provide us feedback if anything is missing. So back to the sample. We have that value pair, property name and property value.

Now, in GraphQL, we have a different organization. We have the properties as results and in an array. And then we have the name and the value. So it's a bit more verbose in this case because we are specifying what we want so we know what are the values that we are getting.

But that also gives us the flexibility to have more typed data. So we know that we have the name, the value, and the property definition. So you see that some of those objects have a property definition like a specification that is a volume. And there is also a description for that.

In this case, we have length as cross-section. So I know what kind of data I'm getting back is not simply a data. There is a definition behind that. And this is also part of the schema, which is an important part of GraphQL you're going to get there.

Just another example that we have more and more data with name, value, and the property definition, which is quite important to understand the data that we're getting. Now, when we go to GraphQL, there is different ways to understand how it works. And now we're getting a bit more into the tools environment, right?

So one interesting tool is the GraphQL Voyager. And for that, we're using the schema of the GraphQL API. And the schema contains a definition of the data. So in this case, we see that we have a very spaghetti kind of graph that shows us how a specific data model is defined.

So that's the schema of the data model. Let's see that in a bit more details here. That will play nice. So we have in this case for the exchange, right? So I can see how the hubs and projects are organized and how they link to each other.

So at first, it may look very complex and very spaghetti kind. But as you learn more about the schema, you get more and more comfortable on how the elements are organized. So probably one of the biggest learning points on GraphQL is to understand the schema of the data, how the data is created, because you need to understand how hubs connects to projects and projects connect to designs and to elements.

And then once you know how to navigate through this to this spaghetti, we know what kind of information you can get and how to get that information inside the elements. This is another example with the Voyager but in this case using the manufacturing data model.

So we see we have the basic queries. We have projects, items, but we also have components, which is a bit different from the AEC environment, where we have elements. Right? So different environments, different data models.

We have different schemas that we can see here on these Voyager too. And we have to always think about the elements, the objects in the fields we have. So in this case, for this example, we have the element, which is the object, and we have several fields there.

In this case, the ID name, property, those are the fields we have inside the element. So again, getting more and more comfortable with the schema that defines the data model. When we are making the queries, we can create functions that have inputs. And it's usually a good, very convenient way to explore those queries with the graphical tool.

And we have the sample where we have-- sorry-- we have variables for the graph for the queries-- in this case, the exchange ID, element filter. So we specify those variables in the query. And then we pass those variables once we make the query that applies to the GraphQL Explorer.

But also when you're using a package to make REST calls to that to make the calls to GraphQL, you always have the query and the variables for that query. And the query just makes it easier for you to convert between types.

Let's say you have strings and numbers. So it's easier to do that with variables then instead of converting everything to string. We also have aliases, which is easier way to organize the information we want.

So in this case, we see that when we're making the query we're specifying that instead of just getting all the properties with a specific filter, we say that we can organize those properties that comply with that filter as operational properties and as volume properties.

But as we can see here, those two options are just getting properties. But we are organizing them in a way that the result comes a bit cleaner. So it's easier to read and easier for someone else to maintain that later. Right?

We can also create fragments, which are pieces of our query that we can just reuse. So in this case, I have a fragment that contains the result name value. And when I'm defining the query, I can just reuse that fragment. So it makes the query less verbose as we evolve and we make more complex queries. Right? We want ways to make that less verbose.

And we can also have directives, which is a way to have very long queries that will we have pieces of that query that will be enabled or disabled, depending on how we define those directives. Right? So again, another way to have more human-readable queries.

And last, something that we don't have yet-- we're still working on that-- is how to change the data and how to create data. Right? They are called mutations. We don't have support for that yet. We have a few.

We have some support for mutations on events but not for actually change the data. So something that will take us some time to get there. I'm talking a lot about this GraphQL Explorer. There are different versions of that, one for each data model.

Eventually, we are going to merge all those tools into one. But this is essentially just a sandbox to test and explore the queries that we have. And each of those explorers are connected to one data model. You always need to sign in because this is your data. So it's password-protected, but those explorers are ways to explore your data.

So here is the Data Exchange Explorer, where we can get information about exchanges, of course. And when we run the query, you can see that will query against my results. As you can see on the top right, it's signed in as a user. So it's always the information for that user.

And the queries that I have defined here on the GraphQL Explorer because I'm defining query get exchange info. That will show up on the top as well. So I can navigate that and go back to my queries.

This too is very convenient because it will save those queries on your local browser. So once you come back, you can get back to where you started. Another example there, again, with variables, where we have some variables at the bottom left. And once we run the query, that will replace those values and get the precise information that I want.

This last example uses the manufacturing data model. And, again, it's using variables to get hubs, projects, and components. And I'm just getting a specific component inside my model.

Again, very convenient because I'm just getting the information I'm looking for. It's always very convenient and easy to get precisely what I'm looking for. There are several tools to use with GraphQL. We've been using this GraphQL tool, but there are more options.

You can always use Postman, Insomnia. There are lots of plugins for VS Code and many other extensions as well. There is the Apollo plugin that is quite famous, and there is lots and lots more. Again, GraphQL is not something just from Autodesk. It's an open source and is maintained by Meta/Facebook. There is a lot of community around that.

And here is just one last page on the Postman, how it works with Postman. It's kind of similar, right? We have the query at the middle center. We have the variables at the right center and the results at the bottom. And Postman is something that many of us use. So it's not very convenient, and information is there.

All right. Now moving to a more specific realm on the AEC data model. And that's really where the AEC meets GraphQL. We've been talking a lot about the benefits of GraphQL and how that helps us use more and more the data that we want in a more convenient way.

But now, again, summarizing that, it's a single endpoint. We don't have a fixed structure for the data that we want. We define the data that we want, and there is no over-fetching. We're just getting the information we want because we specify the query, and it's very efficient resource-wise.

We're not transferring lots and lots of megabytes of data across the web. We're just transferring the piece of information that we want. It's very granular and very specific. I can specify version, filters, and all of that. So again, lots and lots of benefits, lots of advantages of using GraphQL. And that's why we are moving to use that.

Here is another example, now getting more specific to the AEC domain. Right? We're specifying the design by version number. And I'm specifying a filter that I want, a property name, external ID equals something. And I want the properties that match the name's length. And for those properties, I want name, value, and property definition.

Because of that, I'm only getting that property. I'm not getting anything else. So my query, it's been very, very specific. So my result is also very, very specific. We can have it very human-readable. In this case, let's say I want to get all the elements from the wall category.

So I just say property.name.category double equals walls. If I want all the instances, I just say element context equals instance. If I want to get something that was modified by user, I just say last modified by email, and then I pass the email. I have that.

And I can only get-- if I just want to get some of the information, I can say that I have an array of properties and with length and area. And then I'm only getting those properties. I'm not getting anything else. So it's easier to read.

There's a lot of geek stuff here as well, but it's easier to read compared to a query in REST that I have to specify in different ways. But when I say [INAUDIBLE] say, for instance, this double equals, it's kind of standard for comparing and also because if I want to do contains, I have to put something in between. But I'm going to show some more examples there. It's readable, but we have to get used to it.

Now, again, comparing with data management, where we have different ways to-- when we have a way to get hubs and models inside that hub, I have to look at my lineage versions and some definition that are used by Autodesk. But compared to data management, I would have to get hubs for each, and navigate between different hubs and projects, and then go to content, and then get all the items.

Here, I can only say-- I can directly say that I want all the versions inside my project. So it's very direct and easy to access. We talked a lot about the schema, which is how the data is defined. And here is a more visual representation of part of the schema.

This is not the schema. It's just similar to that, but we see that we have at the very top the data model, the designs, the versions. And inside that, we have all the elements. And the elements are related to each other. And also they are related to each other using the references, the properties. And all those properties are connected to the properties definition.

Again, this is a graph kind of representation. And here we have a very simplistic version of that but shows us how the overall information is organized there. Back to our example. We had an example like that for manufacturing data model. But for Revit data, for AEC data, we have name and value again with, let's say, Revit category, and Revit family name, element name. And that compares to what we see on the Autodesk viewer.

We have no [INAUDIBLE] model [INAUDIBLE] model tree on the bottom left with walls, basic walls, and the element names. And inside those elements, I have more and more properties that will also show up on the query. So if I get all the properties for an element, I'm going to get together all the elements, all the organization there, and also all the other properties I have for those elements.

Now, again, we're talking a lot. There is lots and lots of content here to digest. Let's see some samples now in action, how that works, how fast it is. We are showing this GraphQL Explorer, showing a few samples of that GraphQL Explorer.

And that is very convenient to understand the schema. We can try our queries quick and easy, and also it's connected to the viewer. So it's easier for us to learn more and understand how it works. And we can also query across multiple projects, so it's very convenient for that because we can query all the elements by hub, all the elements by project, by folder, and we can use those RSQL filters to get to the precise information that we want.

So now showing the GraphQL Explorer for the AEC data model. So in this case here, I have GitHubs. So something that is interesting is that if I mouse over inside Hubs, I can see some information about it. So this tool is connected to the schema and is connected to the data that I have there.

So if I click here and I click on Hubs, that will open the documentation that I see here on the left that I can then use to understand better what will be coming out of my GitHubs. So I see that I have pagination and results.

So if I click on Results, I can see that will be a type of hub. And I have ID name. That's what I have here, name and ID. And I can also explore a bit more on projects. And because that, I can go-- on a single query, I can get all the hubs and projects.

If I click on Projects, I can see what else I have there. I have filters, and I can specify filters, and, again, just keep diving in into which information is available. But let's see how that plays out. So let me resize this.

So it takes a few seconds to run, a few moments, a few milliseconds to run the query. I have lots and lots of data with Autodesk. So I'm getting all the hubs that I have. And again, I have all the names, and I have all the IDs.

And if I go to my second tab, I can get all the projects for a given hub. So in this case, I'm going to request the ID and the name. But I'm also requesting the alternative representation of that project, which will contain the external project ID, which is the project ID used by that system.

So if I run that query, I can see there is an ID for the data model, the name of that project. But I also have the ID that is used on the external project on the alternative representation used in this case by ACC. So that's what I use on ACC to represent this project.

I can query the designs by project. So I have a project, and I want to see all the names of the designs inside my project with the version, with the file you are in, and the version you are in.

So if I run this query, I can see that I have this design. That's the name. That's the idea of the design. And if you are-- used to use the viewer, you know that you need the version you are in to view that model. So again, I'm listing all my designs and on that project.

With a single query, I don't have to go through each folder or each file to each piece of my project to get the information. It's all there in a single place. Now, I can also get all the elements inside the design.

So let's say I have a design ID. I'm specifying a filter, and I have a pagination as well because I'm going through page, one page two. So in this example, I already went through this sample. So I know that I'm not starting with page one. I'm starting with a specific page, just show how it works.

Hopefully, that will work. OK. Now I'm getting all the walls. Sorry. And I have the ID name and the properties, and I have all the properties. I'm not putting any filter here. But the interesting piece is that I'm already on a plus one page, right?

I'm not on page one anymore because I'm specifying the cursor here. So comparing to REST, I still have to do multiple queries, one for each page. But I'm just doing one query to get all the elements inside the design that match a specific criteria.

OK. So moving back here, we'll keep moving. There are many, many more queries that we can do. So we learn a bit more on how to organize the queries and how to use variables, fragments, directives. But the really interesting piece is to use RSQL to filter out what we want.

So in this case here, I'm saying that for a specific project I want all the elements that match the category lighting fixture. Sorry. Lighting fixture. I want an additional filter that says that the name property lamp contains-- you see that instead of double equals I have equal contains equals, right?

Contains A-19, and it's a type. So as a result of a query like this, I'm getting all the types of lighting fixture that contains A-19. So it's very powerful to know, for instance, if I'm using a specific kind of a specific type of lamp inside all of my designs inside my project.

So let's say I can change this query to get air conditioning unit. And I can query for the manufacturer information to find all the designs that I'm using an AC unit by this manufacturer. So, again, very convenient way to search across the project.

I can specify several filters, and I can get the precise information I'm looking for. So I may have this one here, lighting fixtures, and let's run this just to compare, just to add a bit more complexity. Right?

I'm saying I don't want all the properties. I just want the design option for those designs, right? So, again, that query, but I'm just getting the design option. So, again, more and more filters. The more I filter, the more specific is the data that I get back.

Now, before we go there, just come back here. Another example is where we have a search that will go across all the designs that I have. And I'm getting everything that contains furniture and everything that is a type instead of an element.

And instead of getting the properties, I'm getting the external ID and the file version you are in. So if you used to use the Autodesk viewer, you know that you need the [? URN ?] to open the model, and you need the external ID to highlight that element.

So this kind of query gets us very close to do a search on our model. It's a very precise search. But I can now open this model in the viewer and use a filter to highlight this specific element. So very precise choice, but it's a way to do a query, to do a search.

Now, we're seeing lots of independent queries. We can also use that to create dashboards, which is very, very convenient for us. Oops. So let's see the sample on a dashboard, right? So this is another sample, and I'm going to select my hub, and I'm going to select my project.

And what it's doing here is going through all the designs inside my project and creating a dashboard for that. You see there is a pagination. So that's why you see 50, and then 100, and then more and more. So for this dashboard, I'm doing a RoomsTakeoff.

So I'm getting all the rooms with some information about those rooms in a format of a table and the same kind of Takeoff in format of a bar chart. And the second sample, the third box here is a doors Takeoff.

And if I sort by here, I can see the height, width, and the element name. So it's a kind of Takeoff kind of dashboard. And as you can see, it's quite fast, quite powerful, and allow us to do this kind of dashboard.

One interesting thing about this sample is that if you go to the developer tools and go to the console, it outputs the queries that are doing, all the queries, including pagination. So I see that I'm using get-- let me zoom in a bit more here.

In this example here, you see that I'm getting all the elements by project. I'm passing the project ID. I'm then using a filter to filter by doors, and element context equals instance. And you see that the last piece is a pagination.

I have a cursor because I'm not on page one anymore. But I still want the next page. So I get the result here. And I'm asking the name, properties, and I'm filtering the properties by element name. Again, I'm being very precise. I just want this property. I don't want all the properties, just this one.

So very powerful and very convenient to use. So this sample is a good way to see how fast you can get the data across all the designs inside your project. Oops. Already showed that one. Come back here. OK.

To finalize, what's next and how to start using it? For the AEC, so for the manufacturer module and in data exchange, they're already available. You can use that today. It's available in production. The API is still in beta, but for the AEC data module, it's still in beta. And you need Revit 2024.

You would need to enable that on your ACC hub. So the best idea is to use a development-specific hub, not use your production. And we have samples for you. So you can use the samples, code samples, documentation. All of that is available so you can build your own queries.

We have a Vanguard Program, which is a way for you to get to be close to us and know what we are working and where we're moving next. And that Vanguard includes access to the private and public data around the AEC, manufacturing, data exchange. All of those data initiatives are part of the Vanguard. So you can use your phone to get the QR code and join the program.

All right. Last, I know that we have lots and lots of questions. So you can always use the aps.help@autodesk.com to ask your questions about any of the data models and how to use GraphQL with that.

We are always available there. So that's the best place for you to get support for your data model development and Autodesk and APS development in general. So ask a question. Don't be shy. Talk to us. Get help. We're here to help.

With that, thank you very much for watching this presentation. I hope it was useful and looking forward to see your results with the data models, including manufacturing, AEC, and data exchange.