Learn Apollo: Build GraphQL Apps with React, React Native or Exponent
learnapollo.com
learnapollo.com
What we really need is a decent GraphQL server. The client isn't difficult anyway.
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 permission system with a group of beta testers which leverages the Graph structure of your backend to specify data access rules.
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.
Again, thanks a lot for your great feedback. And I'm glad you enjoyed using Graphcool so far!
(I'm not affiliated with either of them. Just wanna know)
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) :)
Subjectively, having played with both, I chose scaphold (over graph.cool and reindex) for a few reasons:
- pricing model makes a lot more sense to me. Graph.cool tiers their pricing on user counts, which makes very little sense to me for a product the cost drivers of which are storage and throughput. They also apparently count a user once they register, with no clear way of handling inactive users (can't be good for your LTV calcs). Reindex was also suboptimal imo, with steep jumps from free tier to paid. They also charge based on 'operations,' which, while less so, also seems strangely divorced from what I imagine their cost drivers are. Scaphold seems to have taken firebase's pricing model, which was a smart move
- storage. Graph.cool has really low storage per tier. Reindex bills storage separately from 'operations' and only charges in $50 5GB chunks (5.1 GB last month? Sorry!). Scaphold again copies firebase's pricing with small, inexpensive increments.
- ui. I didn't use graph.cool's ui too much, but I'm very happy with scaphold's. Afaik reminded didn't have any ui to speak of--someone correct me here if I'm wrong. You can build your entire schema in scaphold's ui (with very helpful tool tips most of the time) , manage integrations (which, generally, just make certain queries/mutations available), and view some pretty thorough analytics on your app. Coming from firebase, which has been really neglecting web app users in favor of mobile lately (imo), this was really nice.
Lastly, I'm new to graphql, but as I understand it, scaphold has added some nice features on top of the API. It seems to mirror PostgraphQL (a postgres <-> graphql utility), and adds pretty robust support for relationships (1:1,1:many,many:many). My schema is highly relational and, so far, it's a breeze.
I will note that graph.cool seems to have much more newbie-friendly docs, and maybe more comprehensive docs over all. Scaphold's docs are okay: they're wider than they are deep (maybe a paragraph for every feature w/ an uncommented snippet), there are some obvious mistakes, and some parts of the docs are scattered between the docs page and the UI's tool tips. When I had problems, though, their team got back to me w/in minutes (on email and slack).
To be clear, I'm not affiliated w/ any company discussed here--I'm just a user shopping for a firebase replacement.
That said, if you're considering the product, here's a ref link--$10 for you & $25 for me https://scaphold.io/referral?ref=99XXP3
Our pricing structure has been like that since we started a year ago. We have learned a lot since then and you touch on some important points. We have put of updating the pricing model because we have been busy improving docs and working on the product, but expect a complete revamp early next year.
If you want to talk more you can always reach me on soren@graph.cool :-)
Turns out the most basic feature of a BaaS app, the console, is practicaly unusable. Too buggy, too many errors happening. After struggling with it for a while I switched to graph.cool.
The small issues that I had with it were resolved by the team immediately. Smooth sailing from then on
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!
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.
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.
Apollo Client is a Javascript library that can be used in any front end where you want to use data from a GraphQL server.
It's incrementally adoptable, so that you can drop it into an existing JavaScript app and start using GraphQL for just part of your UI.
It uses TypeScript.
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 monitoring.
[I work on Optics.]
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.
We're committed long term to Meteor and Apollo both, and view both technologies as critical to the long-term success of the company. Apollo originated as a project to improve the internal data system of Meteor, but we saw that it was useful in a wider context. Today you can use Apollo with Meteor or with any other JavaScript or native mobile technology.