mglukhovsky

You can see a complete example in the accompanying Gist for this article: https://gist.github.com/lopopolo-stripe/e00b4bfa0839c125ed7a...

You could also look at the new W3 Payment Request API [1] that stores card details securely in modern browsers.

Stripe has a Payment Request Button that enables one-click buying with Apple Pay, Google Pay, or the Payment Request API. [2] The button will choose whichever method is best and available for your specific browser.

[1] https://www.w3.org/TR/payment-request/

[2] https://stripe.com/docs/stripe-js/elements/payment-request-b...

Elements lets you define validation behavior and styles by listening to event handlers that emit errors[0], and you can specify custom web fonts with the `fonts` option[1].

You can see a few examples of Elements using custom validation and fonts here: https://stripe.com/elements/examples

[0] https://stripe.com/docs/stripe.js#input-validation

[1] https://stripe.com/docs/stripe.js#stripe-elements

I appreciate the detailed analysis. A few comments:

This post is probably going to make some people involved with RethinkDB very angry at me.

Actually, our community has always felt the opposite. Performance and scalability issues are considered bugs worth solving. That may have been the reaction of one or two community members, but that doesn't represent our values at all.

A RethinkDB employee told me he thought I was their biggest user in terms of how hard I was pushing RethinkDB.

This may have been true (at the time) in terms of how SMC was using changefeeds, but RethinkDB is used in far more aggressive contexts. Here's a talk from Fidelity about how they used RethinkDB (for 25M customers across 25 nodes): https://www.youtube.com/watch?v=rm2zerSz6aE

SMC did seem to uncover a number of surprising bugs along the way: I would describe it as one of the more forward-thinking use cases that pushed the envelope of some of RethinkDB's newest features. This definitely came with lots of performance issues to solve along the way. I appreciate William’s tenacity and patience in helping us track down and fix these along the way.

In particular, he pointed out this 2015 blog post, in which RethinkDB is consistently 5x-10x slower than MongoDB.

It’s worth pointing out that this particular blog post raised serious questions in its methodology, and recent versions of RethinkDB included very significant performance improvements: https://github.com/rethinkdb/rethinkdb/issues/4282

Even then, the proxy nodes would often run at relatively high cpu usage. I never understood why.

I'd have to double-check with those who are far more familiar with RethinkDB's proxy mode, but it's because the nodes are parsing and processing queries as well, which can be CPU-intensive. They don't store any data, but if you use ReQL queries in a complex fashion (especially paired with changefeeds) it's going to require more CPU usage. We generally recommend that you run nodes with a lot of cores to take advantage of the parallelized architecture that RethinkDB has. This can get expensive if you aren't running dedicated hardware.

The total disk space usage was an order of magnitude less (800GB versus 80GB).

RethinkDB doesn't yet have compression (https://github.com/rethinkdb/rethinkdb/issues/1396). Between this fact and running 1/3 the number of replicas, the reduced disk usage is not surprising.

I imagine databases are similar. Using 10x more disk space means 10x more reading and writing to disk, and disk is (way more than) 10x slower than RAM…

This isn't necessarily true, especially with SSDs. RethinkDB's storage engine neatly divides its storage into extents that can be logically accessed in an efficient fashion. This is particularly valuable when running on SSDs, which are fundamentally parallelized devices. RethinkDB also caches data in memory as much as possible to avoid going to disk, but using more disk space doesn't immediately translate to lower performance.

One other interesting detail: since RethinkDB doesn’t have schemas, it stores the field names of each document individually. This is one of the trade-offs of not having a schema: even with compression, RethinkDB would use more space than Postgres for this reason. (This also impacts performance, since schemaless data is more complicated to parse and process.)

Not listening to users is perhaps not the best approach to building quality software. [referring to microbenchmarks]

I think William may have misinterpreted the quote he describes from Slava’s post-mortem. Slava was referring to benchmarks that don’t affect the core performance of the database or production quality of the system, but may look better when you run micro-benchmarks: https://rethinkdb.com/blog/the-benchmark-youre-reading-is-pr...

We have always had an open development process on GitHub to collaboratively decide what features to build, and what their implementation should look like. I’m not certain what design choices William is suggesting we rejected. One has to only look at the proposal for dates and times in RethinkDB to see how this process and open conversation unfolds with our users: https://github.com/rethinkdb/rethinkdb/issues/977

Really, what I love is the problems that RethinkDB solved, and where I believed RethinkDB could be 2-3 years from now if brilliant engineers like Daniel Mewes continued to work fulltime on the project.

RethinkDB development is proceeding after joining The Linux Foundation, despite the company shutdown. We believe that with a few years of work, RethinkDB will continue to mature as a database to reach Postgres’ level of stability and performance. We’re exploring options for funding dedicated developers long-term as an open-source project.

My thoughts: whatever technology you end up picking is going to have tradeoffs depending on your use case (and the maturity of the technology) and it's going to come with baggage. That's true of Postgres, MongoDB, RethinkDB, any programming language you choose, any tools you pick. If you're willing to carry that baggage it can be worth it: especially if it gives you developer velocity or if the problem you're solving is particularly well-suited to the tool.

Pick the technology that will have the least baggage for your problem. I often recommend Postgres to people, despite being one of the RethinkDB founders. Pragmatism wins over idealism, every time.

Thanks Mark, I appreciate the kind words.

This should be working again (we had to move quickly to set up some of our community operations.)

You can also always reach out to me directly: mike [.at] rethinkdb . com

It's also worth noting that changefeeds are highly scalable: you can run tens of thousands of them on a single node, and scale them out linearly from there (even as they're scoped to specific queries.)

Obviously the performance characteristics will be impacted by the volume of changes that arrive to the database, but the architecture to support this is highly parallelized (all the way down to cores on the CPU.)

RethinkDB pushes well past 15 nodes: teams have demonstrated north of 25-30 nodes with linear scale.

Horizon will be joining under RethinkDB's aegis at The Linux Foundation: a new community-driven release is in the works.

Yes, Horizon was included. Since it's MIT licensed, it's already freely available, but it joins The Linux Foundation under RethinkDB's aegis.

I think you might mean the Jepsen tests: https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5

This might be a useful read: https://rethinkdb.com/faq/

It explains RethinkDB's ideal use cases, explains how to compare it to other databases, and details some of the differentiating features.

Some of the code and content was heavily used internally, but we never invested time to properly package it for public consumption.

We also briefly had a closed-source version of RethinkDB that has a few useful features for larger teams: we're excited to be able to merge these back into the project.

Bryan Cantrill posted his thoughts on the CNCF's decision to donate RethinkDB to The Linux Foundation here: https://news.ycombinator.com/item?id=13579544

We wanted to share RethinkDB's next steps in our new home with The Linux Foundation.

We've also had a lot of folks ask if they can donate to support the project. Stripe has generously offered to match up to $25k in donations (which will help fund server costs and future development.) You can learn how to contribute to the project with OSS contributions or donations here: https://rethinkdb.com/contribute

To add to that: one of the great consequences of this change is that a large amount of RethinkDB source code that was previously unavailable as open-source code (including some unreleased features for RethinkDB, copious amounts of artwork and content, and build / performance scripts) will now also be steadily open-sourced.

We felt that it was too important to let the work we created have a life of its own and establish its own life in the open-source community. It's wonderful to see this finally happen.

Hey everyone, thanks to the rest of the RethinkDB leadership team and the CNCF for their hard work! This wouldn't have been possible without a lot of effort from our dedicated community.

You can read the announcement on RethinkDB's blog to find out about the project's next steps: https://rethinkdb.com/blog/rethinkdb-joins-linux-foundation/

We've had a lot of folks ask if they can donate to support the project. Stripe has generously offered to match up to $25k in donations (which will help fund server costs and future development.) You can learn how to contribute to the project with OSS contributions or donations here: https://rethinkdb.com/contribute

This is a safety check. Because of the dual-writing pattern, there's no reason it should be necessary, but with migrations it makes sense to be extra-cautious and to double-check your work.

We plan to share more posts on our data infrastructure: like you pointed out, there are lots of useful patterns to share. In the meantime, I’ve updated the post to be more consistent (thanks for mentioning it.)

Chris, thanks for leading the charge. We're very interested in having RethinkDB join an open-source foundation.

I've been overwhelmed (in the best way) by the level of support we've seen from the community in planning RethinkDB's next steps. If you'd like to contribute to the open-source project in any way, let us know [1]. You can also join us in #open-rethinkdb on our public Slack group, where we're starting the planning process.

Feel free to reach out to me with ideas and questions. Thanks for all the kind words.

[1] https://goo.gl/forms/tFjI4JI4AvIcPi3D3

I can only speak for myself, but as one of the founders, I don't regret a minute of the time I've spent building RethinkDB.

I have to defend Compose.io here. They spent countless hours working alongside the RethinkDB team to debug problems, provide fixes, and improve the product.

We have always considered them key collaborators and contributors to the RethinkDB ecosystem. There is a conversation to be had about the difference in business models between RethinkDB and Compose.io, but I would never describe it as anything but friendly cooperation and mutual support.

I'm glad to hear that they expressed their dedication to preserving RethinkDB's open-source future. We're working to contact all the folks in our community to decide the next steps together. I'm excited to keep working with them.

Thank you for your kind words on our behalf. Hopefully the product we created together with the community will have a bright future.

I agree! I'll take a look at updating our RSS feed in a bit to include the full articles.

Good idea! We forgot to push a RSS feed. Here it is: http://horizon.io/feed.xml

If you like, you can also turn off the web UI completely with `rethinkdb --no-http-admin`.

While it is challenging to build a Django integration, there are some options for working with RethinkDB. You can check this StackOverflow answer for a starting base: http://stackoverflow.com/questions/28001980/how-to-setup-ret...

Jorge Silva (@thejsj) also wrote this demo app to show how you could pair MySQL with RethinkDB when using Django: https://github.com/thejsj/django-and-rethinkdb

We maintain a stable LTS release (v2.0) for those who cannot tolerate breaking changes.

Feature releases (e.g. 2.1, 2.2) include new features and do break compatibility on occasion (so we can quickly introduce new behavior). Any breaking changes are well-documented in the release notes[1], so you can have a smooth upgrade path.

Minor releases (e.g. 2.1.1, 2.1.2) do not have breaking changes, only bugfixes and minor improvements.

I just opened an issue so we can document this more clearly: https://github.com/rethinkdb/docs/issues/948

[1] https://github.com/rethinkdb/rethinkdb/releases

You may find this article helpful: http://rethinkdb.com/docs/memory-usage/

The article describes how RethinkDB uses memory to reduce disk access and process queries, as well as how to reduce its memory usage with `--cache-size`.

A Windows port is in progress (https://github.com/rethinkdb/rethinkdb/labels/windows), but it will take some time to complete. Windows support is one of our most-requested features: https://github.com/rethinkdb/rethinkdb/issues/1100

Amazon changed the image format, and we've been working to update our images to use it. Here's some more detail: https://github.com/rethinkdb/marketplace-ami/issues/1

If you like, you can launch a 1.16 AMI, ssh into the instance, and run `apt-get update && apt-get install rethinkdb` to update to RethinkDB 2.1.

Thanks for being patient -- we'll get the official images updated soon.

Compose.io offers hosted RethinkDB instances, I'd recommend them: https://www.compose.io/rethinkdb/