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.

[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.