Live data from Hacker News

Learn Apollo: Build GraphQL Apps with React, React Native or Exponent

learnapollo.com

21–30 of 39 posts

Re: Learn Apollo: Build GraphQL Apps with React, React Native or Exponent

#21
post #14

All these GraphQL solutions seem to focus on the frontend and assume there's a magical GraphQL server somewhere. But GraphQL Just shifts the hard work from the client to the server and I haven't seen any good solution towards security (except storing all the possible queries a user may access, which kind of defeats the purpose of GraphQL in the first place) and performance (a large query is usually resolved to thousa…

In addition to graph.cool, there's scaphold.io. has any body used these two and can share their experience?

(I'm not affiliated with either of them. Just wanna know)

Re: Learn Apollo: Build GraphQL Apps with React, React Native or Exponent

#22
post #19

From the creator's of Meteor. What kind of long-term commitment plan do you have for Apollo?

Thanks, I didn't know that. That certainly explains the high polished look of Apollo combined with the seemingly non-existent business model. I tried Apollo Optics - horrible brand name BTW, everyone I mention it to here in Germany thinks of the eyeware retailer - and while it was easy to integrate and nice to look at, it provided little actual value compared to existing tools in the same space of performance monitor…

Would you mind sharing what metrics and analysis are the most important for your GraphQL API? (Or what you would find most valuable if you could get it?) What tools do you use today?

[I work on Optics.]

Re: Learn Apollo: Build GraphQL Apps with React, React Native or Exponent

#23
post #14

All these GraphQL solutions seem to focus on the frontend and assume there's a magical GraphQL server somewhere. But GraphQL Just shifts the hard work from the client to the server and I haven't seen any good solution towards security (except storing all the possible queries a user may access, which kind of defeats the purpose of GraphQL in the first place) and performance (a large query is usually resolved to thousa…

That's a really good point, kabes. At Graphcool ( https://www.graph.cool ) we're working on exactly what you're describing. We're putting a lot of work into optimizing for the best possible performance while providing a powerful and flexible API. The key for this will be combining GraphQL and serverless technologies like AWS Lambda to implement your business logic. Concerning security: We're currently testing a new p…

Hey there, there is one thing I've been wondering about with Graphcool: What's your plan for supporting BI solutions? As it stands there doesn't seem to be a way for non-developers to do any analysis on the data that resides inside Graphcool.

I also have a bit of feedback on the webiste: It looks way way overloaded. I get it, it's cool how easy it is to use, but there are ~6 full blown code examples on very different things. The FAQ link doesn't take me to a FAQ page that answers the questions I have, but instead takes me to a guides page (which is only a little bit better than the FAQ link in the footer that takes me to the main page again). The competitor matrix feels really arbitrary. Fields with almost the exact same texts yield you a "++" and the competitor a "-"? Why? I feel like a dedicated "features" page would do a much better job at highlighting your strengths.

Re: Learn Apollo: Build GraphQL Apps with React, React Native or Exponent

#24
post #13
post #3

Hey :-) we just announced this. Happy to answer any questions. Here's the accompanying blog post https://dev-blog.apollodata.com/learn-apollo-build-graphql-a...

Can you give a comparison between Apollo Client and Relay? And if you know about upcoming Relay 2 features, I'd like to hear about it too in the context of Apollo Client. If you have time, I would love to hear about your (and everybody else) opinion/prediction where we're going with client data management/server communication in the future. What's your take on client databases? Thanks!

(I work on Apollo)

It's hard to know exactly what will be included in Relay 2, so we'll have to wait to make a comparison. Apollo came after Relay 1, and so has been designed with a few key differentiators: (1) flexibility, since it's built in a modular way and has a lot of hooks into internals, (2) less opinions, because it works with any GraphQL server and doesn't require a particular type of schema, and (3) optimized for devtools, since it doesn't generate dynamic queries on the fly and is built on top of Redux. You can see the new dev tools we launched yesterday here: https://dev-blog.apollodata.com/apollo-client-developer-tool...

As for client/server communication in the future, it seems there are two main camps right now:

1. Lossy APIs - this is if you use a REST API or GraphQL to send data to the client. The server knows a lot more than the client does, and the API returns only what the client needs to know at that moment. This has the advantage that it doesn't impose any limitations on your backend schema or storage, so you can put a REST or GraphQL API on top of literally any backend.

2. Database replication, like Meteor or Realm. In this case, the client asks for objects and they are replicated to the server via some kind of push mechanism. In this case, the client has a much easier time predicting server operations and achieving consistency. On the other hand, the server has to be much smarter and this places a lot of restrictions on what kind of database you can use. For example, Meteor essentially requires MongoDB, Realm has its own database.

With Apollo we're trying to build towards the best implementation of approach (1) because our main goal is to enable decoupling between the client and server.

Re: Learn Apollo: Build GraphQL Apps with React, React Native or Exponent

#25
post #23

Earlier quoted context omitted.

That's a really good point, kabes. At Graphcool ( https://www.graph.cool ) we're working on exactly what you're describing. We're putting a lot of work into optimizing for the best possible performance while providing a powerful and flexible API. The key for this will be combining GraphQL and serverless technologies like AWS Lambda to implement your business logic. Concerning security: We're currently testing a new p…

Hey there, there is one thing I've been wondering about with Graphcool: What's your plan for supporting BI solutions? As it stands there doesn't seem to be a way for non-developers to do any analysis on the data that resides inside Graphcool. I also have a bit of feedback on the webiste: It looks way way overloaded. I get it, it's cool how easy it is to use, but there are ~6 full blown code examples on very different…

Hi hobofan (funny name btw), really good questions: 1) BI/Data analysis for non-developers: It's not a feature we're providing yet out of the box but it's on our roadmap for the upcoming months. For now we're focussing on the best possible DX. 2) FAQ link: Yup, you're right. That's broken right now. We're fixing it. 3) Competitor matrix: Good point, we'll try to make this more clear/objective. 4) Dedicated "features" page: I agree, we'll consider it while restructuring the page.

Again, thanks a lot for your great feedback. And I'm glad you enjoyed using Graphcool so far!

Re: Learn Apollo: Build GraphQL Apps with React, React Native or Exponent

#26
post #19

Earlier quoted context omitted.

Thanks, I didn't know that. That certainly explains the high polished look of Apollo combined with the seemingly non-existent business model. I tried Apollo Optics - horrible brand name BTW, everyone I mention it to here in Germany thinks of the eyeware retailer - and while it was easy to integrate and nice to look at, it provided little actual value compared to existing tools in the same space of performance monitor…

Would you mind sharing what metrics and analysis are the most important for your GraphQL API? (Or what you would find most valuable if you could get it?) What tools do you use today? [I work on Optics.]

The most important metrics are the traditional ones that Optics focuses on like latency percentiles and throughput. We are currently using NewRelic and Loggly. Since both the NewRelic agent and our logging system allow us to tag requests, the grouping by query structure that Optics provides, doesn't really add value. (EDIT: Further, both NewRelic and Loggly provide a better interface for zooming in on interesting areas in time.) From a operations perspective a GraphQL and a REST API aren't that different from each other that they warrant the usage of another tool.

When I tried it, the query execution view also wasn't aware of DataLoader usage. That meant, that once we started optimizing our queries, it looked like many slow parallel queries, which meant that you had to guess what was already optimized, and what wasn't.

Re: Learn Apollo: Build GraphQL Apps with React, React Native or Exponent

#27
post #13
post #3

Hey :-) we just announced this. Happy to answer any questions. Here's the accompanying blog post https://dev-blog.apollodata.com/learn-apollo-build-graphql-a...

Can you give a comparison between Apollo Client and Relay? And if you know about upcoming Relay 2 features, I'd like to hear about it too in the context of Apollo Client. If you have time, I would love to hear about your (and everybody else) opinion/prediction where we're going with client data management/server communication in the future. What's your take on client databases? Thanks!

Sashkos answer below is pretty good.

To get a good understanding of the difference between Apollo and Relay I would suggest going through both https://learnrelay.org/ and https://www.learnapollo.com/ - should be doable in a couple hours.

After that you could take a look at the Graphcool Console https://github.com/graphcool/console It's the most complex open source app build with Relay that I'm aware of.

Re: Learn Apollo: Build GraphQL Apps with React, React Native or Exponent

#28
post #21
post #14

All these GraphQL solutions seem to focus on the frontend and assume there's a magical GraphQL server somewhere. But GraphQL Just shifts the hard work from the client to the server and I haven't seen any good solution towards security (except storing all the possible queries a user may access, which kind of defeats the purpose of GraphQL in the first place) and performance (a large query is usually resolved to thousa…

In addition to graph.cool, there's scaphold.io. has any body used these two and can share their experience? (I'm not affiliated with either of them. Just wanna know)

graph.cool is like iPhone,they are so stable in the services they provide and scaphold is like Note7(just explodes, when you try to push it further). We have been using graph.cool for 4 months now and it just works as it promises to be...!

Re: Learn Apollo: Build GraphQL Apps with React, React Native or Exponent

#29
post #14

All these GraphQL solutions seem to focus on the frontend and assume there's a magical GraphQL server somewhere. But GraphQL Just shifts the hard work from the client to the server and I haven't seen any good solution towards security (except storing all the possible queries a user may access, which kind of defeats the purpose of GraphQL in the first place) and performance (a large query is usually resolved to thousa…

[deleted]

Re: Learn Apollo: Build GraphQL Apps with React, React Native or Exponent

#30
post #21
post #14

All these GraphQL solutions seem to focus on the frontend and assume there's a magical GraphQL server somewhere. But GraphQL Just shifts the hard work from the client to the server and I haven't seen any good solution towards security (except storing all the possible queries a user may access, which kind of defeats the purpose of GraphQL in the first place) and performance (a large query is usually resolved to thousa…

In addition to graph.cool, there's scaphold.io. has any body used these two and can share their experience? (I'm not affiliated with either of them. Just wanna know)

Hey there, I've used both Scaphold and Graph.cool and I would thoroughly recommend Graph.cool.

To understand why, I recommend you have a play with them yourself. It is immediately clear, in my opinion, that Graph.cool is a much better designed product in every aspect. Graph.cool's UX exudes refinement and quality that Scaphold's does not.

An example of this is the fact they invite you to their Slack team automatically when you sign up (i.e. use the email you sign up with to invite you, you don't have to do anything). They really care about their customers, and the Slack community around Graph.cool is much more active than Scaphold's. In fact, it's mostly the community that is buzzing around on Slack, and it's about people learning GraphQL, not necessarily learning how to use Graph.cool. The Graph.cool team seem to be really motivated to help everyone learn to use GraphQL, not just their service. This is also evident if you get in touch with the founders of Graph.cool - they are just nice people to talk to.

Any feature distinction that Scaphold may have over Graph.cool is quickly disappearing. I can only think of one, subscriptions, and Graph.cool has that on their roadmap to be released very shortly. On the other hand, Graph.cool has plenty of features that Scaphold does not, such as Auth0 integration, Relay AND Apollo support (from the same schema), a much better permission model.

Oh, and it's free (for now) :)

Post reply on HN