Implement GraphQL based API

[mbabker]

Phase out the REST API in favor of GraphQL. Should be cheaper to maintain in the long run and allow more advanced queries into the data than what we're exposing.

[alikon]

maybe we should explore this more, but personally i'd like to go with a full redis solution

[wilsonge]

We can’t open the full db. Allowing people to track the UIDs would be too much

[mbabker]

Well clearly we'd still need to filter/restrict results but the main point here was to open the door for advanced queries instead of "just give me a count of all the sites running all the PHP versions since forever".

[wilsonge]

I have no problem with GraphQL in principle just noting it down before we open some redis database in read only to the world :P

[mbabker]

Oh it would be the same fields and constraints as is the case now, just expanding to allow queries on the last modified timestamp or being able to do a query like “number of sites using each database driver for all 3.8 releases”.

On Sat, Sep 8, 2018 at 3:38 PM George Wilson ***@***.***> wrote: I have no problem with GraphQL in principle just noting it down before we open some redis database in read only to the world :P — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWfof21V659ATNVfdhqSx9wViUIqmfIks5uZCq2gaJpZM4NpByv> .

-- - Michael Please pardon any errors, this message was sent from my iPhone.

[Mausino]

I see that Joomla 4 Webservices will use REST API as based API

But maybe i am wrong... roadmap of webservices

It should be implement via https://webonyx.github.io/graphql-php/

Source from shopify about graphql benefits:

What are the benefits of using GraphQL instead of REST?
GraphQL addresses several problems that might sound familiar to anyone who’s worked with a REST API.

REST | Fetching associated data often requires multiple HTTP calls
REST APIs are built on the principle that every endpoint should return only one type of resource. For example, the request GET {shop_domain}/admin/api/2019-10/products/1.json retrieves the information for product 1, but nothing more. This means that if you want a product’s variants, images, and metafields, then you need to make at least four HTTP calls.

REST | Apps receive more data than they need
To solve the above problem, we end up breaking away from true REST APIs by embedding certain associations to certain end-points when the need arises. For instance, GET /products/1 returns information about the product, but also its variants, images, and options. Ultimately we end up with one-size-fits-all responses where you cannot request less nor more than what we give you.

REST | Shopify doesn't know what data an app is using
When an app requests a REST endpoint, Shopify has no way of knowing if it's actually using every piece of data that's returned. It’s similar to doing a SELECT * to a SQL database. This is problematic because when Shopify needs to make breaking changes, such as remove an attribute from a response, it’s nearly impossible to know who it will affect. We know which clients call which endpoint, but we don’t know what subset of those clients are using the attribute that we're removing. Some attributes are also costly to compute. If we knew that the app doesn’t need a costly attribute, then we wouldn’t need to compute it in the first place.

REST | REST APIs are usually weakly-typed and lack machine-readable metadata
While there exists some solutions to the problem of not knowing which data is being used (like JSON Schema), the reality is that most REST APIs do not provide this sort of metadata. The result is that apps rely on documentation, which can become out of date or might be incomplete.

GRAPHQL | Everything is typed and part of a schema
Everything that's available through a GraphQL API is included in its schema. You can use the schema to build queries that return only the data that you need. This solves the problem of over-fetching data. It also means that we know which fields each app is using, making it easier for us to evolve our APIs over time.

GRAPHQL | Everything is available from a single endpoint
All GraphQL requests are sent to the /admin/api/2019-10/graphql.json endpoint, which means that you can often retrieve all the data that you need in a single request. Using GraphQL features such as connections, variables, and aliases, you can make your queries incredibly efficient and retrieve data about many resource types in a single request.

GRAPHQL | Documentation is a first-class citizen
The documentation for a GraphQL API lives side-by-side with the code that constitutes it. Combined with the typed schema, this means that we can generate accurate and up-to-date documentation whenever something changes. Using GraphQL's introspection feature, you can query the schema itself to explore its contents and documentation.

GRAPHQL | Deprecation is a first-class citizen
We can easily mark a part of our schema as deprecated, and this will also be reflected in documentation. GraphQL tooling, such as client libraries, is also expected to communicate to the developer that they're using a deprecated tool.

[mbabker]

@Mausino this repo has nothing to do with the design decisions of webservices in the CMS. If you have an issue with it, log an issue at https://github.com/joomla/joomla-cms

[lancedouglas1]

Have y'all considered Hasura as the GraphQL layer with both permissions and brilliant control?

I've tested it migrating my data out of joomla's mysql into postgres and layering hasura on top.

I'd say that subscriptions to GraphQL is the only thing missing from Joomla.

Also, I noticed someone mention redis on this thread; I'd recommend flink instead of redis for its ability to be subscribed to and meant for continuous unstructured data with layers of processing.

[alikon]

for my personal silly experience redis is the most used tool for this kind of matters anyway my view can be differnt from yours

[stell]

I just wanted to bring this up again. Redis is great, but not really suited for complex data and very specific and varying queries. We are already playing around with the RESTfull Web Services API from Joomla 4 and it's great. However, REST is getting old and compared to GraphQL very inflexible. I can imagine for default Joomla resources the REST API is fine, but when working with complex data structures creating REST endpoints gets kind of silly if you really want to gain added value. Other advantages of Graph QL are known. I don't really have an idea how difficult it would be to make GraphQL available and if it is needed to replace the REST API with it or to put it in as a parallel API.

[wilsonge]

I would like to remind you all this is specifically for the statistics API for Joomla that recieves data from the Joomla Stats Plugin. This has nothing to do with the Joomla Core webservices. You need to post on the core webservices tracker for that.

However I would point you at https://phil.tech/2017/graphql-vs-rest-overview/ (I think @stell you're probably aware from bits of the message you posted - but given people keep ending up here - I think it's worth a link). Graphql vs rest is very dependent on the data your using - and not a strict thing of one being better than the other. As a very general rule - most of Joomla's data resolves around CRUD actions and data (hence the structure of our core MVC Layer). Therefore REST is generally a better fit for core - however the plugin approach will absolutely allow others to implement graphql api's if you want and I'm sure over time you'll see these sorts of things becoming available on JED if there is demand.