djmashko2

One of the developers working on Apollo GraphQL stuff here, happy answer any questions! So exciting to see this on HN.

I maintain a few open source projects, and found this list to align very closely with my own desires: https://davidwalsh.name/45-github-issues-dos-donts

Some highlights:

- Do submit one pull request to address one issue.

- Do submit two pull request to address two issues.

- Do not tack on a minor whitespace or semicolon changes in unrelated commits or Pull Requests, even if the minor change is correct. Make a dedicated commit or Pull Request instead.

In general, the smaller and easier to understand a PR is, the easier to merge. I've seen a lot of PRs lose their way due to a "while I'm here" mentality of fixing code style etc, and it often obscures the real purpose of the contribution.

I think you can build a simple web app very quickly using Create React App on the frontend, and a REST or GraphQL API on the backend.

One great thing about this architecture is that it can scale as the app gets more complex, since you can just add more components to the UI, and more fields to the GraphQL schema, without needing to re-structure anything.

I work on Apollo, a set of tools to make it easy to create and use a GraphQL API, and we have a hello world client [0] and server [1]:

[0] https://github.com/apollostack/frontpage-react-app [1] https://github.com/apollostack/frontpage-server

Yeah I don't think there is a clear story about how to put together a GraphQL server yet. It's not inherently complex but the content isn't there yet. It's something we want to target soon.

Have you checked out Apollo Client? It's an alternative to Relay that works with all GraphQL servers and brings in a lot of the simplicity of Falcor: http://dev.apollodata.com/

It includes features like optimistic UI, easy ways to invalidate cache after mutations, arbitrary pagination models, and more.

(Disclaimer: I work on Apollo)

That's exactly right. We're working on refactoring it as well so that it can be used outside of Redux, here is one of the resulting projects: https://github.com/apollostack/graphql-anywhere

Apollo returns the data in observable form. You never have to deal with Redux directly if you don't want to. Check out the Angular docs for more details.

(Disclaimer: I work on Apollo)

Yes, it was a bit surprising to see "Apollo" separate from "GraphQL" here, since our primary focus is to enable people to take advantage of GraphQL no matter their frontend and backend architecture.

It makes the most sense to make a direct comparison between "Apollo" and "Relay", but they should both be considered a subset of "GraphQL", which is really the core technology that everyone is building on.

However, excited that people like it, and we're excited to collaborate with everyone to make it the best way to use GraphQL in an application!

I can't wait to see how public GraphQL API design evolves. The current state of REST APIs took a long time to get polished up, and this is just the first example of a big public GraphQL API.

I think the most exciting part of this project for the HN crowd is that it's not Meteor-specific. We really want this project to be used outside of the integrated Meteor platform, in all kinds of production applications.

So hopefully it's more like "Meteor is building a reactive GraphQL system anyone can adopt" rather than "adding GraphQL support to Meteor".

We have some thoughts about how the new invalidation system will make offline a lot more feasible. In pub/sub based Meteor apps you would need to reload all of the data if you took too long to reconnect, in the new system you will hopefully be able to get just the diff after a much longer reconnect gap, or possible indefinitely depending on implementation details. This is because the app server doesn't need a copy of all of the client's data anymore.

Can you use NPM packages with JSPM?

I wonder if Maxime has considered using the newly announced Meteor-Electron project to package this as a desktop app - I am really in the market for a simple, open source task tracker that I can run as a desktop app so that I can alt-tab and similar.

If you want to make an app with Angular and MongoDB with minimal code, I think Angular-Meteor is one of the top choices! http://www.angular-meteor.com/

This is one of the places where Meteor really shines, and it will also handle building your code, deployment, realtime streaming, etc.

[disclaimer: I work at Meteor]

I wonder how this compares to Rocket.Chat, another open-source alternative: https://rocket.chat/

As far as I know, this is an issue for every database, no? What are you currently using?

I'm curious - do you think there is room for someone to come along with the right combination of stuff to become the "de facto platform for all web development"?

It's interesting also that people always talk about Rails but don't mention JSP and .NET, which I think are actually a lot more popular last time I looked around. I guess it depends on who you ask.

I feel like JavaScript is in a sweet spot right now because it has the inherent advantage of being the _only_ language you can run inside a browser, so you can do things with it that would be very hard or complicated in other languages.

There's an experiment in progress here, written by Slava and myself (core devs at Meteor) over the course of a week: http://meteor-postgres.readthedocs.org/en/latest/

It suggests that there isn't really that much work to do to make a basic SQL integration story that people can use. At this point when this makes it into core is a matter of prioritization and not stretching ourselves too thin.

Yeah, for a while we had to say ES2015/ES6 in all of our blog posts etc. but hopefully soon things can settle down. Especially when it gets to ES2016/ES7 and above, having the year in the name will be super convenient (like Ubuntu version numbers)

There is no first-party solution for this yet, since React support came out in this release. Hopefully we can make it automatic in the near future. I think this is a key advantage of the Meteor model - since the parts of the stack are expecting to be used together, they can collaborate to achieve functionality like this isomorphic, re-hydrating, SSR.

There are already some community projects working on this functionality: https://atmospherejs.com/reactrouter/react-router-ssr

At Meteor, we're working on solving exactly this problem. We're currently working on a painless integration with React that lets you just add a package to get full-stack data sync, JSX compilation, etc.

Check it out: http://react-in-meteor.readthedocs.org/en/latest/

(I work at Meteor)

React integration should make implementing good server-side rendering much easier. There is already a discussion and community project around this: https://github.com/meteor/react-packages/issues/15

There's a more detailed discussion about mixins vs. other data loading methods on this GitHub issue: https://github.com/meteor/react-packages/issues/25#issuecomm...

That wouldn't be about Meteor 1.2 - I don't think Galaxy will ship as part of a Meteor release, but rather as its own product.

It turns out to not be that simple. My coworker Slava has a talk about exactly this question: http://info.meteor.com/blog/what-does-it-mean-to-be-a-real-t...

(I work at Meteor)

(I work at Meteor)

I'm sorry! I haven't heard any other reports of an issue like this; what browser/system are you on?

I think the intention is to signal that SQL is likely to be one of the things we work on immediately after 1.2 is released.

The way I understand it, a replacement for Minimongo just for reading data needs two things:

  1. A simple filtering/querying API (doesn't need to be as fancy as Mongo)
  2. Change events on filtered views of data so that you can update the view
  when new data comes from a subscription

If you also want Meteor Method-style optimistic UI, then you need:

  1. Tracking of temporary changes from a specific method
  2. Ability to roll back those changes when DDP tells you it's done

Having a mongo-specific syntax isn't crucial, I think.

It would be even more awesome if this supported automatic data caching from subscriptions, like the Meteor web client with Minimongo or meteor-iOS does with CoreData: https://github.com/martijnwalraven/meteor-ios

If it's p2p do you lose the ability to reliably store history and do search on it?