Earlier quoted context omitted.
Are you making the argument that they should have a default API route? I don't think that's very common.
I'm making the argument that I wouldn't rely on an API endpoint to serve up the secrets that enable my application to work. Imagine a network outage or endpoint failure when the app just happens to be redeployed.
Instrumenting Next.js with runtime secret injection
11–20 of 27 posts
Re: Instrumenting Next.js with runtime secret injection
#12Looks like the Next.js gish-gallop machine is firing on all cylinders, augmented by generative AI. .env files are problematic because they often end up in version control or left lying on local disks unencrypted, increasing the risk of a secret leak. They're nearly impossible to manage securely at scale, are difficult to distribute across a team, and offer no access control or security. Sure, if your developers live…
100% agree and we need more people saying it. It is crazy how it got so big. Look at the amount of (breaking) changes that benefit no one except vercel (others cannot really keep up, and that's the plan) and the almost unbelievable amount of sloppy CVEs all over the place (patched automatically if you run with vercel). We get called in after things go wrong to monkey patch it so the business keeps going: nextjs issues are delivering us a lot of work.
Re: Instrumenting Next.js with runtime secret injection
#13Looks like the Next.js gish-gallop machine is firing on all cylinders, augmented by generative AI. .env files are problematic because they often end up in version control or left lying on local disks unencrypted, increasing the risk of a secret leak. They're nearly impossible to manage securely at scale, are difficult to distribute across a team, and offer no access control or security. Sure, if your developers live…
Oh yes, Next.js is on my permanent blacklist of ”I won’t take a job if they use it”. It’s truly one of the worst maintained software I’ve ever used, they break stuff constantly, completely without awareness.
Re: Instrumenting Next.js with runtime secret injection
#14Earlier quoted context omitted.
I'm making the argument that I wouldn't rely on an API endpoint to serve up the secrets that enable my application to work. Imagine a network outage or endpoint failure when the app just happens to be redeployed.
That's a whole category of software that makes large systems work: etcd, Zookeeper, HashiCorp Vault, etc.
Re: Instrumenting Next.js with runtime secret injection
#15Looks like the Next.js gish-gallop machine is firing on all cylinders, augmented by generative AI. .env files are problematic because they often end up in version control or left lying on local disks unencrypted, increasing the risk of a secret leak. They're nearly impossible to manage securely at scale, are difficult to distribute across a team, and offer no access control or security. Sure, if your developers live…
> I'd highly recommend staying away from the dumpster fire that is Next.js. It's too bad it's like the top skill asked for by employers these days, who seem to have no idea what they're signing up for. Oh yes, Next.js is on my permanent blacklist of ”I won’t take a job if they use it”. It’s truly one of the worst maintained software I’ve ever used, they break stuff constantly, completely without awareness.
Re: Instrumenting Next.js with runtime secret injection
#16Looks like the Next.js gish-gallop machine is firing on all cylinders, augmented by generative AI. .env files are problematic because they often end up in version control or left lying on local disks unencrypted, increasing the risk of a secret leak. They're nearly impossible to manage securely at scale, are difficult to distribute across a team, and offer no access control or security. Sure, if your developers live…
> I'd highly recommend staying away from the dumpster fire that is Next.js. It's too bad it's like the top skill asked for by employers these days, who seem to have no idea what they're signing up for. 100% agree and we need more people saying it. It is crazy how it got so big. Look at the amount of (breaking) changes that benefit no one except vercel (others cannot really keep up, and that's the plan) and the almost…
https://getlatka.com/companies/vercel
If there is another sustained recession, I do wonder how these companies will handle the turmoil. Cutting overpaid services seems like a no-brainer if you have to tighten your belt.
I've also never seen next.js mentioned in a job ad where I worked for the last 10 years (greater Boston area), never really heard much from them during the meetup scene during that time either (2015-2020). I wonder if these customers are more associated with SV businesses, where VC's force their portfolio to buy services from each other.
Also can't imagine v0 not being a money drain.
Re: Instrumenting Next.js with runtime secret injection
#17Looks like the Next.js gish-gallop machine is firing on all cylinders, augmented by generative AI. .env files are problematic because they often end up in version control or left lying on local disks unencrypted, increasing the risk of a secret leak. They're nearly impossible to manage securely at scale, are difficult to distribute across a team, and offer no access control or security. Sure, if your developers live…
Re: Instrumenting Next.js with runtime secret injection
#18Looks like the Next.js gish-gallop machine is firing on all cylinders, augmented by generative AI. .env files are problematic because they often end up in version control or left lying on local disks unencrypted, increasing the risk of a secret leak. They're nearly impossible to manage securely at scale, are difficult to distribute across a team, and offer no access control or security. Sure, if your developers live…
Which web framework would you recommend?
Re: Instrumenting Next.js with runtime secret injection
#19Looks like the Next.js gish-gallop machine is firing on all cylinders, augmented by generative AI. .env files are problematic because they often end up in version control or left lying on local disks unencrypted, increasing the risk of a secret leak. They're nearly impossible to manage securely at scale, are difficult to distribute across a team, and offer no access control or security. Sure, if your developers live…
> just so a secret (of any kind) is never required on the client This is how web clients usually work though not NextJS special at all. You have a HTTP only cookie for authentication and proxy requests through your backend to authorize client to perform actions that depend on secrets. I’m not a NextJS proponent and have experienced frustrations running into its limitations but I think in this case it’s unfair to mali…
And I already know what the answer is, it's "anticipate every possible future scenario that your web program might encounter, and design your server/client structure perfectly the first time! What's so hard about that?"
This experience with Next.js has made me quit the Javascript/Typescript communities of web frameworks entirely. Burned by Gatsby and GraphQL once, shame on them. Burned by Next.js though...
Re: Instrumenting Next.js with runtime secret injection
#20Looks like the Next.js gish-gallop machine is firing on all cylinders, augmented by generative AI. .env files are problematic because they often end up in version control or left lying on local disks unencrypted, increasing the risk of a secret leak. They're nearly impossible to manage securely at scale, are difficult to distribute across a team, and offer no access control or security. Sure, if your developers live…
Which web framework would you recommend?
I also subscribe to the HATEOAS principle and really like the idea of separating the visual and business logic layers so that I can mix-and-match technologies based on the problem domain. The glue layer I'm using is HTMX - it can be dropped in anywhere, allowing you to pair any templating language for the front-end with any general-purpose language on the back-end.
As an aside, I have a personal definition of "vibe-coding", which is when the language/framework is so good, that it pretty much gets out of the way and lets you solve the actual problem at hand, instead of wrestling with a language/framework/way of life/whatever. That's what Django/Python, HTMX, some Alpine.js and Tailwind (just the classes) have done for me