Openstreetmap-website: Plans for GraphQL support?

[sunapi386]

Numerous API calls could be simplified with a single GraphQL. But frontend (id) would need to be updated in parallel.

[tomhughes]

We have no plans to rewrite the API.

[tomhughes]

By the way API users go far beyond one editor, and there is no way we could hope to coordinate update dozens of different clients to a completely different API!

[mmd-osm]

@sunapi386 : out of curiosity, can you provide a few examples what kind of simplification you had in mind, and for which use cases those would be relevant?

[sunapi386]

@mmd-osm I think "what kind of simplification" isn't the right question, because GraphQL would be unifying all the different endpoints into a single URL and all the CRUD functions would be preserved -- so there is no simplification as to what the functionalities are.

As to "which use cases those would be relevant", I was looking to make use of OSM backend as part of my mapping infrastructure with my own data set. I am considering to write a custom frontend that consumes a select portion of that. It would've been easier to consume GraphQL because of its contractual basis, so I wouldn't need to hunt around for the data I needed.

@tomhughes you wouldn't need to coordinate existing clients with a different API. Effectively we'd open up a single new endpoint for handling GraphQL features, and anyone who wants to make use of that can do so. It's common to have a GraphQL layer to bridge existing services, essentially providing a translation service to existing APIs.

[mmd-osm]

GraphQL would be unifying all the different endpoints into a single URL and all the CRUD functions would be preserved

Upload operations in particular are quite complex due to lots of dependencies in the data model, and most of data is currently part of some XML document. Also you want to avoid single object uploads as they're quite slow.

I was looking to make use of OSM backend as part of my mapping infrastructure with my own data set. I am considering to write a custom frontend that consumes a select portion of that.

Ok, that would probably be out of scope for the main OSM site then. People tend to use Overpass API for those sort of things over here (see https://wiki.openstreetmap.org/wiki/Overpass_API/Sparse_Editing) .

[HolgerJeromin]

What would be the benefit?
Beside having a lot of work in all ends :-D

[sunapi386]

What would be the benefit?

@HolgerJeromin it would be all the benefits of using GraphQL, which you'd be better off reading an article about it. But in short, you can query/mutate/subscribe the data you want with a single endpoint (e.g. example.com/graphql) , guaranteed the response types, don't need to read the REST API docs to understand what responses the server provides, and optimize network bandwidth. And in a conventional REST API, if someone decides to change the response to a certain endpoint, you (the API consumer) need to care. But with GraphQL you don't.

[sunapi386]

Upload operations in particular are quite complex due to lots of dependencies in the data model

@mmd-osm I don't know much about upload operations in the context to OSM. But I do know GraphQL wouldn't affect how you process that data.

As for the slow single object upload perfomance, I assume the workflow you're talking about is the "map edit then upload", where the inefficiency would be re-uploading data that haven't changed. In this case we should optimize how we store the data and upload just the deltas.

And thanks for the pointer to Overpass API.

[bfreeds]

An API query language that is straightforward and aligns with web standards instead of an esoteric query language would be a huge simplification.

[mmd-osm]

@bfreeds : it looks like you're mixing up stuff. This repo is about the OSM website and the (editing) API. It doesn't even have a query language on its own. Besides, the API usage policy explicitly forbids the use in read-only scenarios (see https://operations.osmfoundation.org/policies/api/).

In case you want to suggest something different for Overpass API, you need to head to their respective repo.