node-bayarea

It was ABSOLUTELY wonderful to have Firebug back in 2006/7 timeframe. I really enjoyed using it and looking at the DOM and whatnot!

In 2022, I'd imagine there is some startup that does this. I'm not asking for something that truly scales to millions of users and has ALL the features of production reddit / hackernews. I'm thinking an MVP production app that has basic things that we all think about that a social networking app would have. I'm surprised that it's still so hard to find a "SaaS in a box" with some sample production apps like Twitter-clone/Reddit-clone, etc that does all the wiring for us.

very interesting site!

I meant I'm looking for something that takes away majority of the work/headache for what I want like retool + firebase (potentially)

Good question. This is in the B2B2C. I doubt I'll get millions of people per day LOL. So anything decent but something that I can quickly set up is what I'm looking for.

Maybe it's Maybelline :)

I dont like it at all. I think it just tries to solve something that's not a big deal.

Amazing video about main stream media's conversation https://www.youtube.com/watch?v=1XMJTWD2mzs

Fantastic surprise!

Not exactly true. There are things like "Redis on Flash" that redis.com offers for large sets of data. If you enable it, most of your data gets stored in a Flash memory and hence super cheap, in fact even cheaper than things like DynamoDB and stuff.

You can store Terabytes of data in Redis. Just google it.

Remember, many of these things that get released are usually just vaporware. They may become better 6 months or a year later, or, they may never see the light of day.

Introducing Redis Launchpad! . A central place for quality sample apps that use Redis as a realtime platform and a primary database. Explore architecture, data modeling, commands, and more.

https://launchpad.redis.com

RediSearch

Amplitude is NOT a great product when you actually try to implement it. I have seen at least 3 companies pay for them based on how good it looks and all the promises but only to realize that the integration is actually very hard, and the data in Amplitude is often wrong! Also they dont do a good job in sending data back to things like SFDC and what not.

Telling it from real experience.

Completely agree about the Object-relational mismatch. The general term "Impedance Mismatch" is used in several industries to mean the loss in efficiency due to increase in complexity.

"Object-Relational Impedance Mismatch"[1] is been around for decades. Martin Fowler[2] and others who are deeply technical (think Sr. architects, CTOs) use this all the time.

[1] https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe... [2] https://youtu.be/qI_g07C_Q5I?t=98

Good question. Redis Timeseries is just a different data structure and works alongside other data structures so it wont add too much Impedance when compared to having different data in different systems. On the other hand, imagine you used Redis for just cache and used TimescaleDB instead. TimescaleDB is based on PostgreSQL, so you need to use a different thought process, different SDK, different commands (SQL), different hosting, different devOps, etc. And for performance purposes, say stored some data in Redis for caching, now you have additional overhead because you need to now manage data in two systems. And let's say TimeScaleDB needs some other adopters to sync the data to Kafka, and Kafka needs Zookeeper, now all of a sudden you have 4-5 systems.

The goal of the Impedance impedance mismatch test is to identify such scenarios using a simple calculator and avoid them. In 2021, there are many single systems like Kafka, Redis, Cosmos, etc which can do multiple things way more efficiently. Many of these are OSS projects, so you wont get vendor lock-in.

I think the article is mainly attempting to provide you with a tool to calculate complexity. You can add additional columns to the calculator and make it your own for your needs. It's been used by some companies internally to compare complex systems or to migrate from an old system to a new system.

It's just a tool to calculate complexity. You don't need to use Redis or Kafka or any thing used in the article. If Kafka or CosmosDB or something else works better, that's great too.

Totally agree. Re: Zookeeper, Kafka are apparently going towards removing Zookeeper. The goal is to give you a calculator to measure complexity. You can totally add it to your calculation.

You can certainly overlay cost to the calculator by adding an additional column. Cost should not be just the storage layer cost, it should include HR cost, licensing cost, overhead cost, basically TCO for each system in the data layer.

But I think generally by simply listing all your systems, you'll already kind of know how complex or simple your system is.

Can you give me a concrete example of were you'd contort if you were to use Redis versus Postgres? BTW, I'm just trying to really find an actual proof as opposed to mere anecdotal knowledge.

I understand that Postgres is an awesome DB. But my point is, why not use Redis especially when it comes with RedisJSON, RediSearch, RedisGraph, etc and gets most of the things done without any SQL. Why should we stick to the traditional approach? Is there any actual proof that Redis won't be able to handle it other than just guessing?

I'm looking at a retail store app. Redis comes with RedisJSON, Search and other modules to model it. So why not use it?

Here is the article for your reference: https://redislabs.com/blog/dbless-architecture-and-why-its-t...

Hi there, I agree that traditionally (and even now) that's how cache works. But the system like Redis that provides that service has gotten much more powerful over the years and so you can use it as a traditional Db.

The car efficiency numbers came from Inside EVs as the article points out. I think they did a pretty thorough job. https://insideevs.com/features/392202/ice-vs-ev-inefficient-...

Do you mean there is some kind of memory leak? Maybe you should try upgrading to the latest Redis. It's a lot more feature rich and powerful these days.

I don't think that's the spirit of that blog you pointed out. Redis is quite different from traditional databases. And so things work differently and some features may be important in RDBMS, might not be that useful in Redis because of how different they are.

I think the blog talks about that in two sections. "First reason to use rollbacks: concurrency" and "Second reason to use rollbacks: leveraging index constraints" says why it's different in Redis.

Going back to the car analogy, if you are an electric vehicle, some things are completely obsolete when compared with gasoline vehicle.

You, if you look at very large customers of ElastiCache or Redis, or just companies like Twitter, they all use a very large Redis clusters to store Terabytes of data. You can also use"Redis on Flash" and save a lot of money when compared to DynamoDB and others for similar size of data. https://redislabs.com/redis-enterprise/technology/redis-on-f...