derekperkins

Mostly MySQL that is moving to Vitess (transparently sharded MySQL). I believe they use gh-ost for migrations.

The list is innately disingenuous. For most of these products, SSO isn't the sole differentiator between pricing tiers, there are also significant functionality differences.

Vitess is awesome if you're using MySQL.

Seems like you would just instantiate separate caches per customer if that's what you're looking for.

I think that will eventually be solved by https://github.com/census-instrumentation/opencensus-service

If you don't love Gatsby, you could try out https://github.com/nozzle/react-static

No, federation is still dead in the water.

MySQL has close to feature parity in terms of JSON functionality too.

Saying that dep and prior art has been ignored or not "looked into" is unfair. Russ is very clear about where dep and similar tools fall short of a perfect solution. Not only that, but Google has contracted Sam to help with vgo, since he presumably has the most Go experience in the matter.

I'm sure it's disheartening for people who worked on dep. I've had a great experience with it too, especially after the .4.1 release.

While not everyone agrees, one of my favorite things about Go is that every decision is well thought out in terms of its effects on the entire ecosystem. Just because some other language or toolset does something isn't a good enough reason to force it into Go. I trust the overlords, they've been good to me so far. :)

If you're comfortable with React, it's not a bad choice to use for templating. IMO, a better choice than SSR is using something like https://github.com/nozzle/react-static or https://github.com/gatsbyjs/gatsby to use React to build your static site.

If you like React, you should check out https://github.com/nozzle/react-static

They are both under heavy development. MySQL is still increasing revenue for Oracle, and MariaDB raised another $27M towards the end of 2017. They're both here to stay. The less clear question in my mind is how long they will remain compatible.

JSON has been great in MySQL for a few years now since 5.7, and recursive CTEs are coming in the next couple months with 8.0. I don't think you can make a wrong choice between the two these days, but choosing Mongo over either is almost always the wrong decision.

https://www.infoworld.com/article/3228154/sql/whats-new-in-m...

This is a great use case for kube-metacontroller that was introduced in the Day 2 Keynote at Kubecon. With minimal work, you can replicate a deployment or stateful set, but with custom update strategies.

Live demo: https://youtu.be/1kjgwXP_N7A?t=10m46s Code: https://github.com/kstmp/metacontroller

We use https://github.com/nozzle/react-static with Netlify. If you're a react user, this will feel just like Create React App, where other react static site generators are much more opinionated.

Vitess deserves more love here on HN. It's incredible the way it gives you the best of both worlds (RDBMS and NoSQL). Most operations end up in a single shard, so you have no performance impact and still have the benefit of built in MySQL joins and relational integrity. It is built to be container-native, so the recommended usage is to split into 100-300 GB chunks, which simultaneously makes schema changes take 1/(n shards) of the time for a normal ALTER TABLE.

This may be too late for you, but this is a great library that marries d3 with React. https://github.com/tannerlinsley/react-charts

Why were you replacing gRPC?

Yes, d3-interpolate does a lot of the heavy lifting, but claiming that react-move doesn't provide any value is clearly untrue. - Animation frame management, skipping frames if the cpu is overloaded - React component API: you may not put value here, but some people find that easier to use, especially given the lifecycle hooks

Feel free to wire together your own solution if that works better for you. As for me, react-move is exactly what I need.

Hahahaha

They definitely both have their place in the sun. I feel like most of the time, I'm looking for a preset duration, which requires some experimenting in react-motion. The physics are cool, but can be decently imitated with some good easing functions.

If you look at Greensock, the lite version is 28kb and the max version is 113kb, so it's all relative.

Are Window functions definitely coming in 8.0?

I know that banning databases from k8s is the popular point of view now, but Google has been running databases in containers for nearly a decade. YouTube runs on top of http://vitess.io/, which is a cloud native approach to MySQL.

Certainly approach with caution, but there's no reason for a blanket dismissal of dbs in containers.

TL;DR - etcd is the best, according to coreos :)

You should checkout https://github.com/jumpsuit/jumpstate

It's much easier to reason about, including side effects, while not being too magical.

YouTube runs MySQL on Borg too, and they open sourced their management solution. - http://vitess.io

Best comment ever

YouTube already open sourced their containerized MySQL solution and it works pretty great. http://vitess.io

I disagree with the edit. While they have been responsive, they have been completely useless on my Gold package.

The individual teams however have been fantastic, available on both Slack and Google Groups.