Ok, my bad. But this place is getting plastered with spam, like this paid boilerplate. Show HN is to share your work for the community to checkout and test. This requires a $99,- upfront payment so this is an ad. Nothing more nothing less.
I guess I have a problem with being blasted with paid next.js/node.js templates while having a notification set up for these keywords on HN. It feels like this is just an ad for your paid template. It's a highly congested market segment and I get you need to funnel/guide leads into your checkout page but this is not the place.
Going by your bio one could think this is business oriented. Sorry if I missed the mark. Anyway, I doubt anyone is going to run the numbers for you. I would give this a real life test, even if it was just simulated traffic. Hetzner has been a huge cost saving for me.
Whenever I read posts like this with millions of requests per small time unit, fighting over dollars. I realize I work in a completely different realm. I have barely 60 concurrent users but these users are paying top dollar for the privilege. Can't you make the revenue per request higher so this becomes a none issue ?
Even though I use systemd to manage my primary node app, I started to use pm2 for new projects. It was just easier, better monitoring, cluster option, many easy to configure restart options. I don't think the article makes a good enough case to not use pm2.
I've been playing with Remix.js a bit and come to similar conclusions. I'm not exited to go all in on route actions. I found myself using socket.io with TS interfaces to define the API. I guess pretty similar to how trpc works albeit with a bit more boilerplate. Currently looking into Vike (vite-plugin-ssr) to cut down on meta dependencies.
Samsung doesn't allow security updates while roaming (requires wifi). Another artificial restriction without much consideration for longer term travelers.
Definitely. There is very little talk/discussion about these databases apart from evangelist articles. That's another reason for me to be hesitant to migrate. Still have a ping/alert whenever someone mentions these databases on HN.
I once tried both of these databases with an existing PostgreSQL database. I was never able to convert my pg database to YugabyteDB, YugabyteDB Voyager (a migration tool) would choke during the conversion/migration. I did manage to get a working CockroachDB version but had to drop quite a bit of features and consistency checks. I remember not being impressed with the added latency. Lessons learned: don't migrate existing projects to these distributed databases and only use them in new projects when you are in dire need of a distributed database and are comfortable with the added latency. Mind you, this was quite some time ago, I'm sure things have improved.
I get your point. I see Kysely more as a progression from Objection, but that's not the case if you're not into TypeScript. I was using Knex.js like forever and now switching over to Kysely. kysely-codegen introspects the database on every build, and doesn't massage the output model like for instance Prisma does. The database is leading, the only dependency is the query builder API which feels pretty familiar coming from Knex.js. So even though it's new and shiny, it doesn't feel like a huge commitment you can't back out of if things go south with Kysely. Anyway, Node.js does indeed not have these "one true way" giants like the frameworks you mentioned. That's a blessing and a curse.
Netflix beats others when it comes to low bitrate high quality streams. At some remote areas with poor cellular coverage, Netflix is the only service that provides a working video stream.
JavaScript (TypeScript) is my all time favorite language. I write code in Go, PHP and Python and have coded in C# and Java. But for me nothing beats the simplicity, ergonomics and maintainability of modern TypeScript.
Great article, with one caveat:
The big upfront question should be; do I need BullMQ (and Redis). I think in most cases a simple DB queue table will suffice, reducing complexity allowing for greater customization.
Same story, Hetzner storage box, local backups and at times a backup to my Android phone. Automated backup testing and a notification on Telegram if anything is amiss.
I don't like the friction introduced by the app router. Even though the merits of layouts, streaming and React Server Components are clear. I have a stable site/app and don't need to migrate any time soon, I rather wait for something better. Which in my mind is something Server Side Rendered, written in TypeScript and close to the native DOM API.
I think supporting React Server Components is at the core of this issue. A ton of changes were necessary to support RSC and a different router is just one of many things that changed. Important features have been sacrificed to make it happen. You for instance no longer have access to the request/ response object in middleware or layouts. Currently playing with Remix as an alternative.