HN user
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 have keywords for next.js and node.js. I should probably filter for /boilerplate/ and /ship/ too.
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 ?
This reads like a very honest reflection and gives back some eroded trust in Vercel.
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.
Being GPT compatible seems to be another major selling point.
I would love to read the full story on this.
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.
Maybe on my end. It doesn't happen in incognito.
The link redirects to google.com
Samsung doesn't allow security updates while roaming (requires wifi). Another artificial restriction without much consideration for longer term travelers.
I'm getting flooded with your backend template posts. I get posting something two times or so, but this is getting out of hand.
Or use something more bare metal and go for a query builder like Kysely.
Did you find the source of this error?
Thanks, will do when I give it another try.
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.
Share the same sentiment and settled on Kysely. Although new, it doesn't try to do too much and has excellent TypeScript support.
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.
I have to give µWebSockets a try sometime soon.
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.
No ads either if you set a private ad blocking DNS server.
Is this specific to Next.js app router? The pages router has been quite good to me, but the app router is something that matches your experience.