[Murkin]

There was a comment on the original blog post that while they (Facebook) use GraphQL they still fall back to Flux for some of the data handling.

Was this solved ? Did they manage to handle all the data needs of their apps with GraphQL or is it still limited to certain areas ?

[HeyImAlex]

They are orthogonal; graph ql is for fetching data and is supposed to be an alternative to writing a new backend endpoint for every ui-thing that needs some slice of data, flux is a pattern for organizing data flow in the UI.

[darknoon]

I think you mean falling back to "FQL," the old SQL-like syntax, since Flux is more of a client architecture thing (paired with GraphQL).

FQL has some holdouts in legacy code, but the vast majority of the iOS app is using GraphQL. There are a bunch of tools built around using it, and it's the "right way" these days. Maybe a year or more ago ago, the notifications tab was using FQL. It makes sense to convert things since the risk in switching is outweighed by a reduction in server CPU, network bytes transferred, and ability of tools to understand the code. When we built Paper, we did notifications on GraphQL because there wasn't the risk of breaking something.

You can almost certainly handle all of your 'data needs' with GraphQL... :D

[woah]

I think the OP meant Flux. I also read about it being used to store things that are not being persisted.

[darknoon]

Fair enough. In that case, yeah, GraphQL is about the server communication and doesn't specify a particular application architecture. There's usually some data you want saved locally and not persisted to the server, though that's not very common in facebook, since eg preferences are meant to work across devices.