Instrumenting Next.js with runtime secret injection | Hacker News Reader

Instrumenting Next.js with runtime secret injection

phase.dev

20 pointsnimishk26 comments

Looks 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 in a bubble and don't know any better. Otherwise, .env files are fantastic because they are dead simple. Keeping them out of VCS is simple. echo ".env" >> .gitignore.

Need to share a secret value? Use any number of secure communications systems your company has in place. Or generate your own from the system that is issuing secrets. It's not the 1950s, when sharing a secret was considered a national security endeavor. This doesn't need to be rocket science.

You can communicate what's supposed to go in the .env file with a .env.template file, with a list of env variables set equal to an empty string.

I'm glad they at least share the nightmare that is client-side environment variables. Prepare to waste days/weeks of your life sifting through unresolved issues in Next.js repo on GitHub, only to discover that you have to re-architect vast swaths of an application just so a secret (of any kind) is never required on the client. This is incredibly challenging and frustrating to deal with, especially when on a deadline and you're 95% done with a working solution.

In typical Next.js fashion, the official documentation for instrumentation.ts is complete dog crap. It's deceptively short, making the naive developer think it's simple to configure. In reality, you should first read through the 50 open and 71 closed GitHub issues related just to instrumentation (https://github.com/vercel/next.js/issues?q=is%3Aissue%20stat...), and make sure you understand all the undocumented ways in which instrumentation.js will destroy any semblance of productivity or enjoyment of programming.

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.

TIL https://en.m.wikipedia.org/wiki/Gish_gallop

> 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 malign it.

If anything NextJS makes this easier, you just move your function call that uses a secret to a “use server” file and add an authorization check but your client code doesn’t need to change you keep importing it and calling it like a regular async function.

Here's the thing - the other frameworks I work in don't encourage me to require secrets on the client-side, so you're exactly right. The client-server split that is enforced by Next.js's App Router paradigm is not an abstraction, but more like a rift through the center of the web development universe. I don't want to send env variables to the client, but sometimes they have to be shipped with the bundle to cross this great chasm. It's like that scene in Interstellar when Coop and his team gets sucked into the black hole. Him returning to see Murph is like a client issuing a fetch request to the server, as far as Next.js is concerned

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...

it’s so much easier to fix this in NextJS compared to other stacks though, I have done it a few times where I end up w secret using code in the client while prototyping but it’s just a single line of text at the top of a file to make it server and keep the existing async call sites. NextJS is not great at some stuff but moving code from client to server it’s like second to none

> 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 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.

I still don't believe it's that big, but they have had consistent revenue growth:

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.

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.

I agree with everything except "completely without awareness"...the game is called "vendor lock-in" and they're intentionally breaking anything that allows people to use Next.js outside their fancy, expensive ecosystem

Which web framework would you recommend?

Not OP but literally Rails

I've preferred Python-based web frameworks lately. Django has been my primary go-to, but I'm starting to use FastAPI more for very simple web projects that I want up and running in literally 10 minutes (including deployment over ngrok).

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

Interesting. I'll try something like HTMX + daisyUI when I get the chance, though I would prefer a programming language that has a type system (for the back-end).

Try pinggy.io for hosting once ;)

Next.js env var tooling could definitely use some improvement, and pulling from a secure external vault makes sense, but I think there's more to it.

Have you seen http://varlock.dev/integrations/nextjs

"https://api.phase.dev"

100% uptime, I'm sure.

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.

I think it depends on the API - we do this with AWS Secret Managers. I haven't seen it fail but if did it would only effect new instances coming into service so I think we'd have to be pretty unlucky for it to have a noticeable impact.

This wasn’t an AWS Secrets Manager example, and yes, there’s a guy named Murphy who wrote a law about this kind of thing.

It's true that anything that can go wrong will go wrong but I wouldn't use that as a maxim to direct designs - risk is one trade-off and it's significance varies.

Nah, we’ve been doing this long enough that handling network failure is just the default assumption now, we should be designing and coding for it, by default.

That's a whole category of software that makes large systems work: etcd, Zookeeper, HashiCorp Vault, etc.

Yes! All built with redundancy in mind.

https://etcd.io/docs/v3.3/op-guide/

https://zookeeper.apache.org/doc/r3.9.3/zookeeperStarted.htm...

https://developer.hashicorp.com/vault/tutorials/day-one-raft

Where should secrets come from then? Burn them into the deployable artifact??? Place them on the host filesystem in perpetuity???

I'm tired of all the Next.js slander. It works great.

Reply on news.ycombinator.com