The awesome-selfhosted project has a nice list of open-source analytics projects. It's really good inspiration to dig into these projects and find out about the technology choices that other open-source tools in the space have made.
https://github.com/awesome-selfhosted/awesome-selfhosted#ana...
Why are Go/JVM/CLR better than V8? Is it the single threaded thing or is there more to it? I thought V8 would be performant especially for this very IO bound use case.
Part of the explanation comes down to the inherent limitations of a dynamic language (javascript) that also happens to be single-threaded by design. No matter how smart the javascript engine and no matter how much it can optimise the code, it can only go so far.
Here you can see a breakdown of different server technologies, and how they benchmark against each other for various typical web-server tasks:
https://www.techempower.com/benchmarks/#section=data-r21
It's really interesting, but of course - not the full picture. And I hope people don't take it to mean that c++ and rust are always the best choice because they're the fastest in benchmarks.
"Potential performance" is not the only thing that matters. I personally happen to love working with nodejs and full-stack javascript (even though I'm a "polyglot"). I think that half the time, the theoretical advantages of more performant software platforms can be vastly outweighed by other variables.
It actually more depends on the circumstances of the project. What skills does the dev team have? What's the larger organisation tech landscape? How much does performance really matter for the use-case? How fast does the project need to go to market? How important is reliability? etc..
For example:
- If I'm a medical device company I sure as hell won't put javascript on pacemakers (I can only hope that's how they think) - I'm using something proven, with as less risks as possible, and with a looong "boring" history: C, C++
- If I'm a bank, I'm putting my bet on safe platform, backed by another big Enterprise like Java (Oracle), Dotnet (Microsoft)
- And if I'm building a e-commerce site, it's totally reasonable to have a php-based backend, alongside a CMS like wordpress
In the case of storywise here, full stack javascript (actually typescript) will do just fine. The performance of Nodejs will be absolutely more than enough, I have no doubt.
Sending pageviews as POST requests is extremenly cheap on the nodejs + mongo backend. And for the admin part, for summarising data over time and querying, mongodb's aggregation pipeline can take you quite far, without the slightest optimisations (indexes or dedicated timeseries collections). But just as a disclaimer - I haven't done the performance tests at large scale yet with storywise's dataset. But I guarantee it'll be fast enough for small, medium, and moderately large sites, as is right now.
Perhaps some people tend to underestimate a tool's performance, and over-estimate the intensity of their own use-cases on the tool. I think any database or server-side framework would get the job done for something as simple as tracking pageviews. Perhaps storywise will even support other databases in the future, to make it easier for people to self-host on their existing databases - postgres, mysql, sqlite, etc.
Could it be done more efficiently? Absolutely. Use rust (or even golang) for the backend; use clickhouse for the database. You'll likely save ~30-40MB of RAM for the nodejs runtime. And you'll be able to query data blazingly fast with a dedicated analytics database, made for the purpose. But at what cost? At the cost of simplicity.
IMO, full-stack typescript is much easier to work with for a project like this, and mongodb is an easy database to either use as a service (for free even) or self-host.
My point with Storywise was - I want a simple tool; simple to host, simple to use, simple to build features on (of course - only if the feature is simple enough...). I leave the complicated stuff for the other similar tools, there are plenty of them out there.
Technology choices: JavaScript and MongoDB
Seems off.