Apollo technical preview

announce
1

Hey everyone,

Today, we published a first technical preview of the new Apollo data stack we are working on! We’re super excited about Apollo and what it means for modern application development in general, and for Meteor apps in particular.

I’m posting here to explain what Apollo is and how it fits with Meteor (for a lot of you this part will be familiar ground), and to give you some hints about how to experiment with Apollo in your existing Meteor app if you feel like trying new things.

SQL for Meteor

By far the most common feature request we hear for the Meteor framework is better support for different data sources, mainly referring to SQL databases and REST endpoints, but also other backends such as Redis and RethinkDB. Investigations into how to best support these backends, discussions about challenges developers face with Meteor’s current Livedata stack, and writing the Meteor Guide led us to realize the next generation data layer in Meteor will need to involve richer subscription semantics—something like GraphQL.

The Apollo project was born from the idea that a Meteor-like data system can be expanded to all backends via GraphQL. Although it’s easy to see Apollo as Livedata 2.0, we’ve given it it’s own name and identity as we realize that the problems it’s going to solve are not unique to Meteor developers, and we want to drive adoption across the JavaScript community.

If you’d like to hear more about the motivations behind Apollo, Sashko’s recent Meteor Night talk and accompanying blog post are a great place to start.

Trying out the Apollo alpha in a Meteor app

Apollo is incrementally adoptable in any JavaScript app, so it’s possible to use it alongside Livedata today in a Meteor app today. You don’t need to change anything about your existing data fetching logic now to take advantage of Apollo for part of your client and server.

Read the docs here: http://docs.apollostack.com/apollo-client/meteor.html

In particular, if you’re using Methods to fetch data non-reactively or you’re syncing data from other sources like REST APIs and SQL into MongoDB, then you might want to look more closely at Apollo now. Over the coming weeks and months, you can expect more guidance about the best way to run Apollo alongside DDP in an existing Meteor application.

Remember of course that Apollo is still in a very early stage of development, and we are going to be actively working on new features and improvements, including support for reactive queries. If this sounds like what you need, and you are thinking of using it in a serious production application, please get in touch as we’d love to hear about what you are doing, and make sure we can prioritize development accordingly!

51 Likes
2

Congratulations and big kudos to the team, I’m amazed how quickly you’ve all made Apollo a reality.

8 Likes
3

This is awesome. Looking forward to playing with it

4

Great!

The code looks pretty low level and boilerplate-heavy right now. That might be because you’re designing it that way or because this is just a technical preview. Are there plans to, for instance, make a Meteor package at some point that abstracts most of this?

3 Likes
5

@rahul I doubt they’ll make a meteor specific package since they’re moving to NPM in general. Apollo is also designed to work on any platform, not just Meteor. I’m sure we’ll see some code and API changes before final production ready release.

6

An example app would be great to have a look at.

7

Had the same thought and then read @sashko 's post here: https://medium.com/apollo-stack/introducing-the-apollo-graphql-data-stack-5d005312cbd0#.qcbmjz6o5

Here are a list of examples he provides in the post:



4 Likes
8

Yeah the examples could be a lot better, but we wanted to get something out there ASAP!

1 Like
9

I’m with Rahul on this, seems like a lot of boilerplate. When it comes to developer friendliness, for me the bar isn’t what’s out there in the JS ecosystem (at floor level) , the bar is the old Meteor framework (pretty darn high) .

2 Likes
10

That’s why it’s a technical preview and not a completed framework. Which parts in particular should we improve first?

Also, note that we are taking a reverse approach to the problem. We’re building the underlying production-ready and scalable technology first, then we are going to optimize the developer experience afterwards. That way, you don’t end up in a situation where it’s super easy to get started with but you get stuck once you have some more serious requirements. (but it should still be super easy to get started with)

18 Likes
11

Sorry, I hadn’t intended to suggest this is incomplete or not going in the right direction! It’s hard to tell right now since it’s early. But it’s great to see this design happening in the open so please keep going :slight_smile: I’ll try to unpack what I was thinking:

I really like this code: https://github.com/apollostack/meteor-starter-kit/blob/master/imports/ui/App.js. I like how it’s pretty easy to read from top to bottom, and how you start by defining the view, then declaring how the view relies on what kind of data, and then finally describing which arguments are passed into the query. There’s probably room to tweak it but overall it composes really nicely with React, and with a file like this you get a lot of information and testability about what a particular component does and depends on in a pretty expressive set of semantics.

Is there a way to get “typed” GraphQL queries instead of having to write them as a multiline string? What’s the best practice here to ensure you get eg. feedback from your editor as to whether the query is constructed correctly? What might the debugging experience look like?

If you move out of App.js and into some of the code that sets up the Apollo client, the query, variable definitions, resolvers and the actual variables themselves are all seperated into bits of code that stand apart and made it hard for me initially to build a mental model of how the code is working together. I’m not sure how to improve on it, though. Maybe a property of Apollo is just needing to take a minute to learn it, which I guess I did back when Meteor launched in 2012 too, so perhaps I’m just rusty with new concepts :wink: But this is the layer that I imagine can be automated or abstracted away to some extent so I don’t have to necessarily deal with networkInterfaces, authorization headers, etc.

Anyway, looking good, more please!

4 Likes
12

Ooh it could be great to do a spike in building a quick auto completion integration for atom. Have you seen the GraphiQL query exploration tool before?

Also, thank you for the specific feedback! That’s great info I can start following up on.

1 Like
13

Yeah, it’s pretty nice, but unlike JSX where Facebook just made a preprocessor that you can hook into your build process, GraphQL appears to still just be a string – so you need to write a lexer or syntax highlighter or something for each tool you want to write it in.

Would it instead make sense to write a preprocessor so you can just parse first-class GraphQL? It seems like DSLs like that would really benefit, and then rather than writing an Atom plugin you can just push the responsibility of building and maintaining that kind of thing into the community, where people can build whatever they want for whichever editor they happen to use.

2 Likes
14

Yeah I mean GraphQL-js already includes a lot of parsing and autocompletion tools, so maybe it won’t actually be that much work! I think this merits a bit of investigation to see what is easy and what is hard.

2 Likes
15

The advantages are big and I can see how with enough sugar thrown at it, this could become almost as easy as the current livequery system (which is hard-to-beat in terms of ease-of-use). However, the server part is only touched very briefly. It seems GraphQL pushes a lot of complexity to the server, and the docs don’t really tackle any of that…

At first glance it also seems that if you have a normalized data model and you would fetch a rather large list of data (e.g. list of posts), with some related data (e.g. post author name etc), this would result in a very large amount of queries?

And while authentication is mentioned, authorization isn’t talked about at all.

1 Like
16

I think this is an amazing way to move forward.

I’m very stunned at how fast you guys are moving. This is awesome. It’s a lot to take in, because I’m used to the current Meteor way and have only glanced at the other way to handle things. But I’m confident there will be an amazing guide to show us the new “right” way. :slight_smile:

1 Like
17

If anyone looking to use Apollo with Mantra, we started a discussion here: https://talk.mantrajs.com/t/apollo-stack-and-mantra/127

@sashko I think we kind a need a RxJS API for the watchQuery API. Then we can work without implementing any wrapper. And I guess that’s something standard as well.

client.watchQuery(...).observable();
2 Likes
18

This looks like a good direction for this to go!

I definitely agree with @rahul on the topic of typed queries instead of a string. I haven’t looked too much into GraphQL as it is, but if it could be a little less verbose that could be beneficial (“query” appears twice, the variables section is potentially redundant and may require a lot of retyping of variables, and a lot of nesting).

I do like the ease of dropping it into the UI. Very simple on that end.

19

@arunoda: watchQuery already returns an observable, although only a minimal polyfill right now. The idea is that you could replace this with a full RxJS observable if it has been installed. Not sure what the best mechanism for that is yet, but it is definitely on our radar and would be great for Angular 2 integration as well.

1 Like
20

Yep I know.
Mantra has built in support for RxJS.
So, we don’t need to build a wrapper if apollo directly supports Rx.

1 Like