Live data from Hacker News

Instrumenting Next.js with runtime secret injection

phase.dev

21–27 of 27 posts

Re: Instrumenting Next.js with runtime secret injection

#22

Earlier quoted context omitted.

Which web framework would you recommend?

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 dom…

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

Re: Instrumenting Next.js with runtime secret injection

#23

Earlier quoted context omitted.

Which web framework would you recommend?

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 dom…

Try pinggy.io for hosting once ;)

Re: Instrumenting Next.js with runtime secret injection

#25
post #6

Earlier quoted context omitted.

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.

Re: Instrumenting Next.js with runtime secret injection

#26
post #6

Earlier quoted context omitted.

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.

Re: Instrumenting Next.js with runtime secret injection

#27
post #10

Earlier quoted context omitted.

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

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…

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
Post reply on HN