41–49 of 49 posts
Earlier quoted context omitted.
You can use the standalone binary (18 MB) to run it. Docker is just one deployment method.
But then why... Hold on, I'm back to my earlier comment.
Earlier quoted context omitted.
You can use the standalone binary (18 MB) to run it. Docker is just one deployment method.
But then why... Hold on, I'm back to my earlier comment.
I do something a bit similar for my own project - it's a single binary REST server, but I still package it up with dpkg-deb and deploy that to a private apt repo so I can update it easily on the servers with "apt-get update && apt-get install blah" and that fits nicely with my existing processes and I can just add the repo and dependency to my cloud-init setup. If I used docker, I'm sure I'd find his docker image the easiest path to getting it installed and updated.
Simple, no-fuss self-hosted server software should really be Rust, or Go / C++ if needed. All three of them allow you embed the UI assets (media, JS, CSS) into the binary and all three work great with key/value stores (badger, leveldb, rocksdb, etc..) or SQLite. There is no install. No setup. No packages to download first. Just a simple binary that respects OS signals, has crazy good throughput, and uses so little me…
Sure, the binaries are bigger, and they cannot run on routers, but you can easily run many of them simultaneously on RaspberryPi, which is usually the bare minimum HW people use to self-host.
Performance wise, difference should be negligible for most use cases, and allows people to write software in the language that's most suited for them and the project.
Earlier quoted context omitted.
The docs literally specify it doesn't "Deploy with a single binary"
It would be nice if people realised that not everything is Linux (or Windows or Mac).
Earlier quoted context omitted.
Almost guaranteed this doesn't build in ~2 years and you would likely need to know all of those languages to fix it.
Encountered the same problem last year. My tech stack was React Native as I was mostly building stuff that has few interactions and it was easy to get something good on both platforms. Then, I got a notice from Google about API version. Updating the project was such a nightmare due to compatibility issue. Some libraries were abandoned. Some had breaking changes. It was easier to write the two native versions than to…
Simple, no-fuss self-hosted server software should really be Rust, or Go / C++ if needed. All three of them allow you embed the UI assets (media, JS, CSS) into the binary and all three work great with key/value stores (badger, leveldb, rocksdb, etc..) or SQLite. There is no install. No setup. No packages to download first. Just a simple binary that respects OS signals, has crazy good throughput, and uses so little me…
Node.js / PHP / dotnet / JVM projects can be bundled to a single binary file. Sure, the binaries are bigger, and they cannot run on routers, but you can easily run many of them simultaneously on RaspberryPi, which is usually the bare minimum HW people use to self-host. Performance wise, difference should be negligible for most use cases, and allows people to write software in the language that's most suited for them…
I think you mean unnoticeable (or similar); the difference in performance (memory usage and CPU cycles) is certainly not negligible.
Earlier quoted context omitted.
But then why... Hold on, I'm back to my earlier comment.
I don't even like docker, but it still doesn't sound that terrible to me. It's an option. Use docker or use the single binary, but presumably if you like docker and have it set up for other things, you'll just use that rather than rolling your own startup scripts etc. I do something a bit similar for my own project - it's a single binary REST server, but I still package it up with dpkg-deb and deploy that to a privat…
Cool project! Also it's welcome resource to learn, since I just started learning Go and was trying myself at an RSS reader ( https://stille.app ).
Earlier quoted context omitted.
For any project that you depend on that has opted into the NPM quagmire, you really should be running `git add --force ./node_modules` and periodically pushing a copy of this to a branch/repo that you control instead of depending on upstream, since most projects that ostensibly use Git tend to thwart its entire raison d'etre—hobbling its ability to do effective version control by abusing .gitignore for their overlay…
The issue was not finding the libraries code. The issue was the churn. So one day, you have a (in my case, small) set of libraries to get things going. Then 2 years after, compilation issues as they all have different requirements. So you have to find another common intersection between them and the node/react-native versions. I should have vendored some in the project. In Android, libraries are much stabler. Depreca…
That's what the whole version control thing that I mentioned is good for. Check out a two-year old copy that resolves to a faithful reproduction of whatever it was you were able to use successfully when you first checked it in.