41 karma · joined June 10, 2011
You want to keep the amount of different data that you are indexing/tagging on low. As an example with my situation, I was tracking what could be amounted to connections between nodes in a very large tree. I had a lot of distinct pairs, which means that I had a high cardinality. When the cardinality increases a query that used to take a millisecond to load could move to a couple seconds.
I can't stress it enough, calculate your cardinality before switching over to it. If your cardinality looks good, InfluxDB is a perfect, logical choice. I really enjoyed it and it is dirt simple to figure out. We had a junior dev just out of college with little experience set it up and get a high level of proficiency in a matter of hours.
Edit: I should point out, I was doing about 10 million records on my db (hosted on a Mac Mini in development!) a day with a 2 week sliding window. I was pushing the data from InfluxDB into custom D3 visualizations. I would cache certain queries in Redis, so I wasn't always hitting InfluxDB with each read request.
.NET Microframework makes it runnable on IoT.
I could see Firebase being a great go to for a certain size of project in the small to medium size that would rather pay for this feature set that using AWS, Azure, Rackspace, etc.
https://www.idlethumbs.net/idlethumbs/episodes/disable-enemi...
Here's the instructions btw. https://developer.xamarin.com/guides/ios/getting_started/ins...
Also, interesting, is the fact that computer engineer "coding" is much more into the state concepts brought up in the article.
With that said even with some years under its belt yet the react community is still in a state of flux (no pun intended), and one is signing up for new and shiny for the next couple of years. One should know that and embrace it going in. There is nothing wrong with that. I feel like we are currently in the "walking" phase with React and have stepped out of "crawling". These tools are helping us learn to "run".
I would build out your project entirely first then look for possible optimizations like this. You will need to see how often this content changes, how often it is requested and the cost of regenerating it. In addition to this, you will want to look at the added engineering costs of this.
If it's something that rarely changes, I usually just have a background job generate it and serve it as static content, but only if it is accessed a lot.
Once you have gone through the course do a small project. I like something more involved than a "TODO" application.