Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

RichardForrester's avatar

Facebook's Relay and GraphQL are going to be HUGE!

I know that I lot of people here don't really care about front-end stuff, but GraphQL has to be implemented server-side and is necessary to use Relay. Relay of course is Facebook's new data-fetching framework that works with React to solve so many of the problems associated with multiple ajax calls on the same page.

In my opinion, we need an update to the React.js series walking through how to get Laravel set up to speak GraphQL. It's actually not super difficult, but it took me the better part of day to also get it hooked into the front end and working. I feel like a video on this could have saved me a lot of time.

I know Relay is a new framework and Laracasts has been putting out a lot of content lately, but I would hope that we would get something on this sooner as it's directly on point with what this site is about.

Relay: https://facebook.github.io/relay/

Laravel GraphQL: https://github.com/Folkloreatelier/laravel-graphql

0 likes
14 replies
RichardForrester's avatar

@tangoG I can't believe there aren't more people here excited about this tech. Granted, I am not a professional developer, I'm actually just an attorney that has recently gotten into development and programming as a hobbie, and to help myself in my job, but it seems strange to me how separated frontend and backend communities are. It's like I'm now a part of two different worlds that don't pay any attention to each other.

In any event, the frontend folks are going apeshit over react/relay/graphql and I'm right there with them. It is completely revolutionary.

I never would have thought there was such a divide.

2 likes
ohffs's avatar

I'm waiting for the next amazing javascript framework. This has been around for days now - so old! ;-)

1 like
yulquen's avatar

@RichardForrester

Well, i would also say, that nowadays the development communites are somewhat divided. But it is a natural thing, when you take a look how huge the development world out there today is. In the "early" days it was a ease of a thing to tackle both development parts and follow the growth on both sides. But today thats even harder with new JS frameworks popping up daily ;-)

But of course, as a dedicated developer you should at least pay a bit of attention and should be curious whats going around.

1 like
RichardForrester's avatar

@ohffs

That is a fun and trendy thing to say for sure, but it really isn't every day, week, or even month that something like GraphQL lands, and nobody is saying learn and use everything. I would just think that if programming is a career choice, you would at least want to know what the new stuff is about... at least enough to know that GraphQL is not a JavaScript framework but a type system.

It is one thing to be skeptical of new tech, it is a different thing entirely to block it all out.

ohffs's avatar

@RichardForrester @willvincent indeed - my old age brings out my sarcastic nature ;-) I've been doing this since the early 1980's so have seen and used quite a lot of new & shiny down the years (and indeed helped make some) ;-) Although on the bright side, it's a long time since anyone suggested I was in any way 'trendy' so overall today is winning ;-)

1 like
thepsion5's avatar

@RichardForrester I think part of the difference has to do with the history of the two communities. Before the days of HTML5, CSS frameworks, and node.js, the separation between server-side languages and client-side languages was pretty wide. HTML, CSS, and later JS for the browser, PHP, Java, ASP, etc for the backend. PHP tends to be a bit less divorced from frontend code due to its origins as a templating language.

Another factor is that front-end developers are more likely to have started out as designers or transition more toward design, which is a very different skillset from typical "software engineers". There are plenty of stereotypes about why you shouldn't let engineers do design, heh.

topvillas's avatar

Is there something I'm not getting here?

I can see why designing queries and knowing what to expect on the client might be nice but why not just use Eloquent relationships and transformers?

It looks a bit too much like a data mapper to me.

EDIT:

And then it hit me! Flexible data queries from the client. Nice!

RichardForrester's avatar

@thepsion5

I agree that traditionally the front-end is closer to design than the back end; however, I would be careful about insinuating that modern JavaScript developers are in any way "less than" when it comes to "real software engineering." I know that is not what you meant, but as I said, I'm fairly new to all of this and I do sense an air of superiority coming from server side folks; which, again from my limited perspective, seems completely unwarranted. With so much of the traditional back-end functionality moving to the client, it actually appears to me that a good amount front-end developers are just as divorced from the "design" aspects of UI. Many have come from frameworks like Rails and Laravel but are now solving the those same problems in the client.

1 like
andrewkhan1's avatar

I am very, very excited for this.

There's so many wrong with the way AJAX is handled on the client currently.

Going to be implementing GraphQL, React, Relay and Flux ('the facebook stack') this coming month of a large scale project, so we'll see how it goes!

1 like
mpchean's avatar

How about a series on Laravel Lighthouse? I think Graphql has the potential to simplify the DB interface. In the meantime there is this series on Youtube https://youtu.be/hvjW-MQEwIM

Please or to participate in this conversation.