arunoda

GraphQL basically allows to build your backend as a well defined API. Then, you can query it from anywhere. It has a good query language and some nice tools like GraphiQL - https://github.com/graphql/graphiql

Meteor is a full stack. It has no direct relationship(or cannot compare with) GraphQL. Meteor also a realtime framework, but GraphQL does not address realtime aspects (yet).

Got it. Will work on it.

Good call. Working on it :)

It's an online course, you need to do some tasks in each lesson. And you get points.

That's why you need to login with GitHub. See more on this: https://news.ycombinator.com/item?id=10384683

Guys, this is an activity based course. That's why you need to login.

You can do stuff and get points. This is a good way to learn something. We've prior experience in with our BulletProof Meteor course.

Yep. We don't render all the pages. But most of the pages of https://kadira.io is public. So, we cache a lot.

Here's another way to jumpstart and learn Kubernetes. Copy and paste this single command into any Ubuntu 64bit VM and it'll give you a single node Kubernetes cluster with all the tools and services(incl. DNS)

    wget -qO- http://git.io/veKlu | sudo sh

Read More Here: https://github.com/meteorhacks/kube-init

So, next two product will be

* One for Chart UIs * One for Alerts

Good Luck with the Tick Platform.

This attack can't solves with Reverse proxies or similar. For proxies, this is just a simple WebSocket message.

So, it's hard (or can't) detect in the proxy layer or with something like Cloudflare. That's why we need a something like Sikka, which understand DDP, the protocol behind Meteor.

Anyway, only we detect bad IPs. It's a good idea to ban them from the network layer.

Yes. I didn't want to rant our NSQ. This is the reason we choose NSQ because of it's simplicity.

We maintain NSQ close to the consumer. We don't our publisher to take responsibility to the message processing. Once it's push to the queue, we need to make sure it's getting process anyway.

That's why we publish same message to multiple queues. All our DB operations are idempotent. So, we are okay with processing the same message multiple times.

But, that all happens inside one NSQ. I mean what if that NSQ server goes down.

We don't have that kind of guarantee in NSQ. To get rid of that, we need to maintain the replication our own by publishing the message to two different NSQ servers.

I think this has a lot of roots from NSQ. But, NSQ has no replication support.

I think built in replication is very nice to have. Would like to try once this arrives.

Not much. If you ask it send a lot of data, then initial HTML will get too big.

Otherwise, it's a good approach.

Thanks :)

It has Fast Rendering https://meteorhacks.com/fast-render/

And you can use cloudflare or some other CDN very easily. See: https://meteorhacks.com/cloudflare-meets-meteor.html

congrats guys :) Very excited to be a part of the community.

Hi,

We've alter our pricing model. See: https://kadira.io/blog/we-heard-you/

Thank You for your input.

Good suggestion FlipOne. Let me work on that :)

Yeah. Currently Meteor performs very well with oplog integration.

We'll show you any potential issues and stay in touch with the app.

Thanks.

Thanks :)

I personally in love with older version of Flash. This reminds me that and I'm gonna use this a lot. Thank you guys.

this is what is recommended for package.json in node. Specially "//" as the key.

Seems like it has collaborative edit feature as well. Specially the last screenshot.

But then they are not loaded in sync. That's not the purpose here. Works for some situations.

Okay. I said that too.

See. Now I've made a fix for it :)

Yes. That's a good idea.

Yes, that's what I was meant :)

Cydia has been updated with a iOS 7 look. But it doesn't support iPhone 5s yet! Hope @saurik is working on that.