i'm failing to understand why this needs a server side component.
SQLite has built in Full Text search.
What's the advantage of using ElasticSearch and having to worry about server costs? Why not just get rid of that and charge me for the app without worrying about never-ending costs?
There are a few reasons for the server side component:
1. Sync between clients. This can also be done by using a Cloud service to sync some database, but resolving conflict data between clients can be tricky.
2. It needs a long running process to check updates for the feeds. It's hard for mobile devices to check updates all the time. So there needs to be another desktop device that check the updates regularly, and may need to sync the articles to the mobile devices. You either sync the whole database, which is a lot for some people (it has been 10GB+ for my own feeds), or you fetch the articles on demand, which makes the desktop client essentially a server.
3. The recommendation features is much easier implemented with ElasticSearch, since it summarize an article's content with a term vector, which you can use to find similar articles. And its search is much more powerful than SQLite's full text search as well.
I understand some people don't want advanced features. Without those features it maybe simpler to just write a RSS client without server. But the advanced features are the motivate behind me writing RSS Brain, and how I find a RSS reader can be more useful.
What's the advantage of using ElasticSearch and having to worry about server costs? Why not just get rid of that and charge me for the app without worrying about never-ending costs?
Because when it's a client-side only app, it's more difficult to charge for subscriptions to ensure that sweet, sweet revenue. Which appears to be the raison d'etre for most software these days. :(
Besides, making it require a server pushes the hoi polloi to register to use "the cloud" (read: someone else's server) rather than just run it themselves.
And if it gets big (it seems like an interesting and potentially popular app), money can be made harvesting PII from those who register.
If you're the app developer, what's not to like?
I'd note that the OP says the code is open source, and so should it be useful, tech folks will likely host their own servers.
This comment isn't meant to denigrate or bash RSS Brain or its author. Rather, it seeks to answer Masukomi's question[0].
My analysis may be dead wrong. It seems plausible, especially since so many folks seem to want to make everything a subscription.
To butcher an old quote[1]: Subscriptions are $10 here, $10 there and soon you're talking about real money.
[1] "A billion here, a billion there and soon you're talking about real money." Usually attributed to Everett Dirksen[2], but it appears that he never said any such thing.[3]
Comments
i'm failing to understand why this needs a server side component.
SQLite has built in Full Text search.
What's the advantage of using ElasticSearch and having to worry about server costs? Why not just get rid of that and charge me for the app without worrying about never-ending costs?
There are a few reasons for the server side component:
1. Sync between clients. This can also be done by using a Cloud service to sync some database, but resolving conflict data between clients can be tricky.
2. It needs a long running process to check updates for the feeds. It's hard for mobile devices to check updates all the time. So there needs to be another desktop device that check the updates regularly, and may need to sync the articles to the mobile devices. You either sync the whole database, which is a lot for some people (it has been 10GB+ for my own feeds), or you fetch the articles on demand, which makes the desktop client essentially a server.
3. The recommendation features is much easier implemented with ElasticSearch, since it summarize an article's content with a term vector, which you can use to find similar articles. And its search is much more powerful than SQLite's full text search as well.
I understand some people don't want advanced features. Without those features it maybe simpler to just write a RSS client without server. But the advanced features are the motivate behind me writing RSS Brain, and how I find a RSS reader can be more useful.
Because when it's a client-side only app, it's more difficult to charge for subscriptions to ensure that sweet, sweet revenue. Which appears to be the raison d'etre for most software these days. :(
Besides, making it require a server pushes the hoi polloi to register to use "the cloud" (read: someone else's server) rather than just run it themselves.
And if it gets big (it seems like an interesting and potentially popular app), money can be made harvesting PII from those who register.
If you're the app developer, what's not to like?
I'd note that the OP says the code is open source, and so should it be useful, tech folks will likely host their own servers.
This comment isn't meant to denigrate or bash RSS Brain or its author. Rather, it seeks to answer Masukomi's question[0].
My analysis may be dead wrong. It seems plausible, especially since so many folks seem to want to make everything a subscription.
To butcher an old quote[1]: Subscriptions are $10 here, $10 there and soon you're talking about real money.
No thanks.
[0] https://news.ycombinator.com/item?id=34190815
[1] "A billion here, a billion there and soon you're talking about real money." Usually attributed to Everett Dirksen[2], but it appears that he never said any such thing.[3]
[2] https://en.wikipedia.org/wiki/Everett_Dirksen
[3] https://www.dirksencenter.org/research-collections/everett-m...
Looks like the code is not open source yet. I'll check this out once it is, not earlier.