Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Relay Modern: Simpler, faster, more extensible

code.facebook.com

Post reply on HN
Print view View original

61–70 of 111 posts

Re: Relay Modern: Simpler, faster, more extensible

#61

Post by vning93 »

voxmatt wrote: post #17

Exciting to see! I've been waiting on this since we decided to use Relay for our application about 6 months ago. Relay is amazing but quite an investment (especially mutations). I'm a bit worried, however, that Relay Modern has focused a bit too much on the internal needs of a massive application like Facebook at the expense of fleshing out some of the rough spots of working with Relay. Simpler, more explicit mutatio…

Very excited as well for the release of Relay Modern! I think overall a huge boon for the Relay developer experience.

I'm with you here on the static queries. We've used Relay a couple of times as well for various smaller applications here and there, but honestly felt the "magic" was too strong. I'm looking forward to building my future apps and try out Relay Modern.

In addition, I want to be able to encourage more applications that build on our GraphQL platform called Scaphold.io (https://scaphold.io) to try out Relay Modern as well since our API is built to the Relay spec. With that in mind, I'm hoping that the spec will be less restrictive in the future, so there's a smaller learning curve for folks trying it out.

As for the concern with focusing on the internal needs of Facebook, I think the experience that they have working with one of the largest distributed systems in the world helps (rather than limits) their vision on what Relay can be. I trust that this is the case, though it would be really great to see some of the tooling for native support (i.e. iOS, Android, etc). I'm sure they've got that somewhere waiting to be released as I can imagine they have plenty of mobile teams at Facebook who aren't using React Native yet.

Re: Relay Modern: Simpler, faster, more extensible

#63

Post by vning93 »

StreamBright wrote: post #6

Is there any great libraries to implement the backend for GraphQL? I think the benefits of using GraphQL on the frontend are pretty obvious, however last time I checked I had trouble of finding good documentation or implementation on how to serve GraphQL requests from the backend point of view.

Great question! There are great libraries like Create-GraphQL (https://github.com/lucasbento/create-graphql) that can help you scaffold an app on the server side pretty quickly, and it's fairly un-opinionated. That one in particular works with Mongo, but I believe they're rolling out support for other data sources as well soon.

In addition, if you're looking for a hi-fidelity way of building apps without having to worry about the server-side, Scaphold.io (https://scaphold.io) is a GraphQL backend as a service that can help. I work full-time here, and we help you get from zero to GraphQL in a matter of minutes.

And with this you have two options:

1) If you want to use the service, by all means :)

2) We're built to the open standard / Relay spec, meaning that if you want to create an app to learn about how the API is structured, that can help as well. Here's more of a primer on how our API is built and works anywhere (https://docs.scaphold.io/coredata/schema/).

Feel free to reach out if you have any questions on our Slack (http://slack.scaphold.io)!

Re: Relay Modern: Simpler, faster, more extensible

#64

Post by vning93 »

leebyron wrote: post #48
johntran wrote: post #29

Earlier quoted context omitted.

1. Could you two do a Reactiflux Q&A? 2. Are people on the Relay OSS team willing to answer StackOverflow-type questions on a certain time? - I would want to be able to programmatically run relay-compiler. Every time I update my client-side code, webpack detects the change and then runs relay-compiler. - And get help figure out some errors related to mutations I'm encountering. I wouldn't want to post these type of t…

Hi, I'm Lee from the GraphQL/Relay team 1. Reactiflux Q&A is a great idea, perhaps someone who organizes that can help set that up. 2. We're a pretty small team and our primary focus is building great software for Facebook and the larger community, so unfortunately our ability to focus on answering questions is relatively limited. Many people on the team occasionally hop into StackOverflow to answer questions, but we…

Hi Lee, Vince here from Scaphold.io.

I can help put you in touch with the guys who run the channel and manage the Q&As. We're actually doing one ourselves on April 27.

I'll reach out on the GraphQL Slack channel.

Re: Relay Modern: Simpler, faster, more extensible

#65

Post by trishume »

cies wrote: post #34
voxmatt wrote: post #23

Earlier quoted context omitted.

Follow-up (didn't see the updated docs). Looks like there is some support for client-side state through "Client Schema Extensions" — excited to play with this. I do also hope that this iteration brings with it better docs — that's the one area where I've looked over at Apollo longingly. On many occasions I've discovered unknown patterns in stack overflow answers that aren't documented anywhere (credit where it's due:…

> the day when Facebook gives up on flow and adopts Typescript will be a glorious, glorious day. I foresee FB to skip TypeScript and go straight with ReasonML[0], as 25%[1] of the messenger code base supposedly is already converted to Reason. And I think that is even more glorious development then FB going with TypeScript. :) [0]: An easier to approach (for programmers coming from mainstream languages; like JS/C++/Ja…

BuckleScript is by Bloomberg, specifically https://github.com/bobzhang, not Jane Street. The developer of js_of_ocaml, the other JS to OCaml compiler, works at Jane Street though.

Re: Relay Modern: Simpler, faster, more extensible

#68

Post by linkmotif »

wincent wrote: post #31
voxmatt wrote: post #23

Earlier quoted context omitted.

Follow-up (didn't see the updated docs). Looks like there is some support for client-side state through "Client Schema Extensions" — excited to play with this. I do also hope that this iteration brings with it better docs — that's the one area where I've looked over at Apollo longingly. On many occasions I've discovered unknown patterns in stack overflow answers that aren't documented anywhere (credit where it's due:…

> I do also hope that this iteration brings with it better docs The docs are very minimal this point with some definite gaps (we had a bit of a scramble to get them written in time for F8), but the point is well-taken: Relay docs need to get better. Luckily, the design of Relay Modern is simpler and easier to understand and explain; there is less (no?) magic involved, so we should be able to get the docs to a much be…

Now that mutations are so much simpler, would be great if there was some discussion of what you get from connections. Previously this was only well explained in blog posts by Huey Petersen.

Thank you!

Re: Relay Modern: Simpler, faster, more extensible

#69

Post by sgrove »

staticassertion wrote: post #56
cies wrote: post #34

Earlier quoted context omitted.

> the day when Facebook gives up on flow and adopts Typescript will be a glorious, glorious day. I foresee FB to skip TypeScript and go straight with ReasonML[0], as 25%[1] of the messenger code base supposedly is already converted to Reason. And I think that is even more glorious development then FB going with TypeScript. :) [0]: An easier to approach (for programmers coming from mainstream languages; like JS/C++/Ja…

Last time I looked at reason it was totally new and there was no tooling etc. I got little support from the gitter or whatever it was. Have things changed? It really interested me at the time.

Worth stopping by the discord [0], it's grown quite a bit and so has the (editor/build/etc.) tooling. There's no Apollo/Relay story yet (that's the biggest missing piece for me on the client side), but everything else is pretty decent!

[0] - https://discordapp.com/invite/reasonml

Post reply on HN