djmashko2

I'm excited to build an example with Relay Modern and the websocket subscriptions transport, should be really cool!

I think the comparison is going to be pretty different for Modern because Relay Modern has some significant changes in the approach.

Hi, I'm from the Apollo Client team.

We're going to write some more content in the coming days or weeks about the differences, but here are some of my main thoughts based on following along during Relay Modern development:

1. Relay uses a build process to generate code for queries. That allows some better performance optimizations and static typing out of the box. However, it prevents you from doing anything which requires arbitrary knowledge of the queries at runtime. It also means that if, for some reason, you can't use the build tooling, you can't use Relay. That's actually the original reason we started working on Apollo instead of using Relay ourselves. Apollo works with regular GraphQL ASTs at runtime, so you can use and write tools to work with those queries in any way you like. While it's not something all apps need, we've found some situations where this is desirable, especially for developers building companion libraries.

2. Relay doesn't have as many facilities for updating the store and working with mutation results. Apollo Client has a unique way to use GraphQL fragments and queries to read and write to/from the store, the most recent of which is described here: https://dev-blog.apollodata.com/apollo-clients-new-imperativ...

3. The Apollo Store is a plain JavaScript object, which means it can be easily serialized, persisted, hydrated, etc. So for example doing server-side rendering where you also hydrate the state is super simple in Apollo. Part of this is because of Apollo's Redux heritage.

4. Developer tools - we think it's super important to understand exactly what is going on with your data, both inside your app and across the wire. That's why in addition to sticking to simple plain objects we worked on some developer tools for chrome: https://dev-blog.apollodata.com/apollo-client-developer-tool...

5. One thing we're really proud of is how different libraries in the Apollo ecosystem are owned and maintained by different organizations from the community. This might make the experience of using it a bit less polished, but means that you can easily contribute or start your own projects if you need some non-standard features.

However, it's also great to remark on the similarities, which I think show that the community and Facebook are converging on some common good ideas. In fact, a lot of the initial decisions on Apollo are based on talking to the GraphQL team at facebook about their experiences:

1. Fully static queries - both Apollo and Relay encourage you to write your queries in the GraphQL language, and avoid manipulating them in unpredictable ways. This is actually one of the ways Apollo diverged from the original Relay release and it's great that it's coming together. Read more here: https://dev-blog.apollodata.com/5-benefits-of-static-graphql...

2. Colocation of data with the view - both Apollo and Relay enable you to do this. This pattern was one of the best achievements of the original versions of Relay, and we think putting the queries and fragments right next to the UI is a great pattern.

Most importantly, though, it's super encouraging that the GraphQL community is gaining another great tool. The best part about GraphQL is the diversity of approaches to servers, clients, and tooling, and that they can all work together through the specification. Really excited to see this release, and I hope we can all learn from each other and make GraphQL a real pleasure to work with.

I cover a lot of these thoughts in my post about misconceptions about GraphQL coming from REST here: https://dev-blog.apollodata.com/graphql-the-next-generation-...

Hey, Sashko from the Apollo team here - we're excited to keep improving Apollo Client and build more awesome tools for GraphQL development! If you're excited about this space and want to work on open source and also commercial products for GraphQL, we're actively hiring for a variety of positions: http://jobs.meteor.com/

Nice, just posted a job! Hope they verify my email soon :]

I think this will be a really awesome way for people to get a taste of GraphQL, without needing to write any code up front!

There are already some other tools that will give you a GraphQL API in very little code, but the fact that this one is hosted means you can host a frontend on GitHub pages or something, send it to your friends, and have a basic app going.

I think you missed that the parent meant that libraries are compiled _before_ publishing. So even if the library is written with ES6 you can simply require it with no build setup.

We built a new GraphQL client that makes it especially easy to integrate with Redux, which also handles all of the related concerns about data caching and state management: http://dev.apollodata.com/

Yeah, Apollo Client helps you do a lot of these kinds of things with GraphQL - deduplicating requests, keeping track of loading states, etc: dev.apollodata.com (disclaimer: I work on Apollo)

If you're interested in Realtime-First development, Meteor has been doing it since 2013 and is very production-ready at this point: https://www.meteor.com/

Congrats on the launch, the new website looks really nice!

I think the focus on integrating with a variety of services really plays to the strengths of GraphQL, and addresses some of the concerns people usually have with backend as a service platforms!

Couldn't disagree more. If I could easily edit somewhere else and paste into Medium I would. For me, the main value in Medium is the follower model, easy distribution, and great UX for reading articles.

If you're doing several interviews with different team members you might be able to ask them about different things.

This is a big benefit of Meteor's build system - it has several improvements that make debugging more straightforward than with Webpack and default Babel import compilation.

This is really great - I have been doing some hiring recently and it would really help me if candidates asked more questions so that I can talk about their interests.

I've found Medium incredibly useful for my open source blogging. First and foremost, it saves me from a ton of hassle picking a platform and theme for something like Wordpress, since it looks great on pretty much every device out of the box. It also has some great features that let people from the community submit posts to our publication.

Also, Medium is a great way for people to follow a variety of blogs - so not only do we still get all of the reads we get from normal sources like Twitter, sharing, etc, but you get a lot of people reading your posts from their Medium feed. In fact, for a lot of posts most of the views come from our Medium subscribers.

I agree with other commenters that setting up a custom domain is a good idea if you think you might want to move to some other platform in the future, especially if Medium is not around forever.

(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.

We decided to ship Apollo under a different name to avoid people's preconceptions that a tool released by the creators of Meteor would only work inside the Meteor platform. What we are seeing is that the JavaScript community has been consistently moving towards focused, decoupled tools, and it made sense to build Apollo in that way. Meteor has also received many improvements to make it easy to work with npm packages, new JavaScript features, etc.

Hi - Sashko here, manager of open source at Meteor Development Group.

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.

Here's the documentation for graphql-tools, Apollo's API definition package: http://dev.apollodata.com/tools/graphql-tools/index.html

Apollo is a GraphQL client - it's an npm package that helps you bind GraphQL data to your Redux store and React components. Here's the website: http://dev.apollodata.com/

> By taking advantage of Babel, ESLint, Atom, etc.

Doesn't TypeScript actually predate all of those tools? So that logic doesn't seem reasonable.

Meteor | Software Developer | San Francisco | REMOTE

Work on open source software to help people build better apps. This includes the Meteor JavaScript app platform and the Apollo GraphQL client and associated tools.

We're a very small but efficient team, with good work-life balance, flexible schedule and location, and interesting and challenging work.

Learn more and apply here: https://jobs.lever.co/meteor/5e11e6cf-5303-4c12-a3e7-11e5f8d...

I built this approach at a hackathon with a friend, it's something that enables people to teach about code by inspecting different parts of a pre-existing project: https://www.codetours.xyz/

Never took the extra time to polish it up after the hackathon, but if someone is interested I'd be happy to work together on improvements.

I think this should work with Apollo out of the box, which is a GraphQL client with similar features to Relay but with deep Redux integration.

(Disclaimer: I work on Apollo)

It's meant to be part of a decoupled stack where you can pick and choose different options for UI, backend, etc. We're constantly working towards having clearer integrations and patterns. If you just want to get a thing built without making decisions and putting in some work for integration, I'd just go with the built-in Meteor stuff for now.

Thanks - we went through a ton of different names, and almost all of them had some sort of collision. We try to mention GraphQL up front on all of the content to avoid extended confusion :]

A lot of people are doing that already! You can use Meteor as the build and deployment system for your app, and use Apollo for data. The main remaining blocker is the accounts system, since it is still tied to a particular MongoDB schema. We're working with people in the community on some ideas about how to make Meteor Accounts database-agnostic, so once that is possible it will truly be possible to build a Meteor app on top of any backend.

I haven't used Vue.js yet (but really want to try!) There's a community integration with Apollo here: https://github.com/Akryum/vue-apollo