6 ms·

We opted for self-hosted next.js as the architecture for the web app we are building because we believed a lot of the hype. The more comments I read about it i

We opted for self-hosted next.js as the architecture for the web app we are building because we believed a lot of the hype. The more comments I read about it in HN, the less comfortable I feel about this decision.

mrits 2y ago
I spent about a week coding in it trying to to figure out what the hype was about. I decided to go with django/htmx. A year later I have absolutely no regrets.
whoknowsidont 2y ago
HN has a very weird mind-set when it comes to JS frameworks. Next.JS is more than fine for 99% of web apps, and the fit only gets better the bigger your web app/platform. In general it's probably the framework that will give you the most bang for your buck.
- bdangubic 2y ago
  expect you know, when you can bypass auth by adding an http header :)
  - whoknowsidont 2y ago
    Not that this isn't a serious attack vector (a possible one), but most implementations are not simply using middleware as a standalone check for authorization then blindly serving paths/content up. That'd be pretty bad architecture in any stack.
    - bdangubic 2y ago
      you probably need to re-define “most” :)
    - apsurd 2y ago
      so having "some protections" like db foreign key scoping that mitigates "well anyone can now bypass auth middleware for any route" makes this… "not that bad on nextjs part" no no, this is absolutely nuts.
      - whoknowsidont 2y ago
        Some of you are ready for an argument, you responded to my post yet seemingly missed the very first sentence fragment: >Not that this isn't a serious attack vector At no point did I say or imply what you put in quotes.
    - arandomusername 2y ago
      I disagree. Why pollute every function with code checking for auth if you can just do it in a middleware?
      - whoknowsidont 2y ago
        You don't do it everywhere. You do it in the source system. The Next.JS application should just be doing "sanity" checks and passing along identity information at most. That belongs in the middleware layer, but it's not authoritative. If bypassing a middleware layer is the one "trust me bro" check you have in your web app, then lol. That's actually really hilarious and you should tell me what company/website that's for so I can submit some bug bounties.
        arandomusername 2y ago
        Isn't next.js the "source system" (or whatever that means) in most cases, since most apps are just next.js + database? I don't use next.js but my understanding is it does both backend and frontend. You will never bypass middleware on my services because they actually always run. If you can't rely on your middleware then you are using the wrong tech. I haven't heard any good reason as to why not have auth in your middleware lawyer. Just attempt to shrug it away as a "trust me bro" check. Are if statements trust me bro too? Only thing you shouldn't be doing is using garbage software like next js From next.js homepage > Middleware > Take control of the incoming request. Use code to define routing and access rules for authentication, experimentation, and internationalization.
        whoknowsidont 2y ago
        >Isn't next.js the "source system" Absolutely not. You are pulling from something else. If you need authorization to view a page that means it's more than likely not going to be SSG or ISR, so both the Next.JS application and the source system should be doing authorization checks. >If you can't rely on your middleware then you are using the wrong tech. "If you can't rely on server less functions to run" I mean, I can't help you there if that's your expectation that serverless functions will always run correctly. >Just attempt to shrug it away as a "trust me bro" check. If you lose identity and your system just chugs along anyway then there isn't a tech stack in the world that can help you. >I haven't heard Because you're being a dense muppet?
- mattmanser 2y ago
  That's a bold claim, that's easy to refute. Next.js is a bad choice for a lot of apps, javascript is slow at a lot of things. Next.js would be a terrible choice for any app that has any non-trivial compute, for example.
  - whoknowsidont 2y ago
    You said it was easy to refute yet you merely stated a mis-framed, contrarian perspective. If you're going to try to be pedantic, do it right? >Next.js would be a terrible choice for any app that has any non-trivial compute Most web apps only need trivial compute. If you're including back-office, source systems in the word "web app" well that's your sticking point, not mine.
    - mattmanser 2y ago
      How is it pedantic? What is your understanding of that word? Why do I have to laboriously explain a fairly simple concept? Here you go: Javascript is a non-compiled language. It is slow, orders of mangitufes slower than other languages such as Go, Rust, C#, Java, etc. Quick note, you might not understand orders of magnitude. It means 10^n times, so 1 order of magnitude slower is 10x slower, 2 orders of magnitude is 100x, 3 1000x, etc. A huge percentage of apps need to do decent CPU work, way more than 1%, which Javascript is not appropriate for. This is HN, you should have rudimentary understanding of the differences between languages. If you want another example, any app that deals with money, decimals or anything mathematical should not be written on javascript. Another massive chunk of apps, way more than 1%. This is because 0.01 + 0.02 is not equal to 0.03 in javascript. People who don't know why that is really shouldn't be commentating on this topic, they're on Mount Stupid in the Dunning-Kruger Effect curve.
      - whoknowsidont 2y ago
        >Why do I have to laboriously explain a fairly simple concept I mean, that's on you. You think you're saying something when you're not and you're trying to justify it. You could just admit you made a mistake and move on with your life.
Andrex 2y ago
> because we believed a lot of the hype Never buy the hype. Buy boring and tested.
Etheryte 2y ago
I'm of very two minds with regards to Next.js. On one hand it gives you so many things to like out of the box, especially when you pair it with something like T3 and the like. On the other hand, it's such a massive goliath that it blows my mind how it gets going at all. It's slow to the point where usually you don't even need to think about performance for basic web apps, but with Next.js you do. Etc. As with any tool, it comes with tradeoffs. Luckily for you, a saving grace of Next.js is that if you ever decide it really does not work for you, you can probably get off of it with comparatively less pain than some other stack change. Your frontend is just React, that will still all work. And if you squint a little, your backend is just Javascript, so you can take it to regular Node land.
no_wizard 2y ago
After going through hell with self hosting and then their platform around version 12 we migrated away. I recommend finding something else. In our case we moved that code to what is now react router 7 but eventually all the react code we have will get replaced by Vue in some manner. We mostly moved away from react as a whole over time
DogPawHat 2y ago
Were you using auth in middleware?
abxyz 2y ago
I like NextJS and actively choose it for many projects. However, there is a big caveat: self-hosting NextJS is not the "real" NextJS experience that most people have because most people are using Vercel's platform and that is the focus of Vercel. Self-hosting NextJS is a bad idea, the benefits of NextJS are inextricably linked to the Vercel platform. You will live to regret self-hosting. I would never, ever consider doing it again and still suffer the pain of it day in day out because of a bad decision I made a few years ago. Use NextJS as expected (on Vercel's platform) or don't use it. If you self-host on your own serverless infrastructure, that's not a terrible idea, but if you try to self-host NextJS on servers, it will fall over at the first hint of traffic.
- urbandw311er 2y ago
  I’d like to understand more about why this is and whether your experience is universal.
  - bodantogat 2y ago
    I’m curious too. I self host on a server, no issues so far.

mrits 2y ago

I spent about a week coding in it trying to to figure out what the hype was about. I decided to go with django/htmx. A year later I have absolutely no regrets.

whoknowsidont 2y ago

HN has a very weird mind-set when it comes to JS frameworks. Next.JS is more than fine for 99% of web apps, and the fit only gets better the bigger your web app/platform. In general it's probably the framework that will give you the most bang for your buck.

bdangubic 2y ago
expect you know, when you can bypass auth by adding an http header :)
- whoknowsidont 2y ago
  Not that this isn't a serious attack vector (a possible one), but most implementations are not simply using middleware as a standalone check for authorization then blindly serving paths/content up. That'd be pretty bad architecture in any stack.
  - bdangubic 2y ago
    you probably need to re-define “most” :)
  - apsurd 2y ago
    so having "some protections" like db foreign key scoping that mitigates "well anyone can now bypass auth middleware for any route" makes this… "not that bad on nextjs part" no no, this is absolutely nuts.
    - whoknowsidont 2y ago
      Some of you are ready for an argument, you responded to my post yet seemingly missed the very first sentence fragment: >Not that this isn't a serious attack vector At no point did I say or imply what you put in quotes.
  - arandomusername 2y ago
    I disagree. Why pollute every function with code checking for auth if you can just do it in a middleware?
    - whoknowsidont 2y ago
      You don't do it everywhere. You do it in the source system. The Next.JS application should just be doing "sanity" checks and passing along identity information at most. That belongs in the middleware layer, but it's not authoritative. If bypassing a middleware layer is the one "trust me bro" check you have in your web app, then lol. That's actually really hilarious and you should tell me what company/website that's for so I can submit some bug bounties.
      - arandomusername 2y ago
        Isn't next.js the "source system" (or whatever that means) in most cases, since most apps are just next.js + database? I don't use next.js but my understanding is it does both backend and frontend. You will never bypass middleware on my services because they actually always run. If you can't rely on your middleware then you are using the wrong tech. I haven't heard any good reason as to why not have auth in your middleware lawyer. Just attempt to shrug it away as a "trust me bro" check. Are if statements trust me bro too? Only thing you shouldn't be doing is using garbage software like next js From next.js homepage > Middleware > Take control of the incoming request. Use code to define routing and access rules for authentication, experimentation, and internationalization.
        whoknowsidont 2y ago
        >Isn't next.js the "source system" Absolutely not. You are pulling from something else. If you need authorization to view a page that means it's more than likely not going to be SSG or ISR, so both the Next.JS application and the source system should be doing authorization checks. >If you can't rely on your middleware then you are using the wrong tech. "If you can't rely on server less functions to run" I mean, I can't help you there if that's your expectation that serverless functions will always run correctly. >Just attempt to shrug it away as a "trust me bro" check. If you lose identity and your system just chugs along anyway then there isn't a tech stack in the world that can help you. >I haven't heard Because you're being a dense muppet?
mattmanser 2y ago
That's a bold claim, that's easy to refute. Next.js is a bad choice for a lot of apps, javascript is slow at a lot of things. Next.js would be a terrible choice for any app that has any non-trivial compute, for example.
- whoknowsidont 2y ago
  You said it was easy to refute yet you merely stated a mis-framed, contrarian perspective. If you're going to try to be pedantic, do it right? >Next.js would be a terrible choice for any app that has any non-trivial compute Most web apps only need trivial compute. If you're including back-office, source systems in the word "web app" well that's your sticking point, not mine.
  - mattmanser 2y ago
    How is it pedantic? What is your understanding of that word? Why do I have to laboriously explain a fairly simple concept? Here you go: Javascript is a non-compiled language. It is slow, orders of mangitufes slower than other languages such as Go, Rust, C#, Java, etc. Quick note, you might not understand orders of magnitude. It means 10^n times, so 1 order of magnitude slower is 10x slower, 2 orders of magnitude is 100x, 3 1000x, etc. A huge percentage of apps need to do decent CPU work, way more than 1%, which Javascript is not appropriate for. This is HN, you should have rudimentary understanding of the differences between languages. If you want another example, any app that deals with money, decimals or anything mathematical should not be written on javascript. Another massive chunk of apps, way more than 1%. This is because 0.01 + 0.02 is not equal to 0.03 in javascript. People who don't know why that is really shouldn't be commentating on this topic, they're on Mount Stupid in the Dunning-Kruger Effect curve.
    - whoknowsidont 2y ago
      >Why do I have to laboriously explain a fairly simple concept I mean, that's on you. You think you're saying something when you're not and you're trying to justify it. You could just admit you made a mistake and move on with your life.

Andrex 2y ago

> because we believed a lot of the hype Never buy the hype. Buy boring and tested.

Etheryte 2y ago

I'm of very two minds with regards to Next.js. On one hand it gives you so many things to like out of the box, especially when you pair it with something like T3 and the like. On the other hand, it's such a massive goliath that it blows my mind how it gets going at all. It's slow to the point where usually you don't even need to think about performance for basic web apps, but with Next.js you do. Etc. As with any tool, it comes with tradeoffs. Luckily for you, a saving grace of Next.js is that if you ever decide it really does not work for you, you can probably get off of it with comparatively less pain than some other stack change. Your frontend is just React, that will still all work. And if you squint a little, your backend is just Javascript, so you can take it to regular Node land.

no_wizard 2y ago

After going through hell with self hosting and then their platform around version 12 we migrated away. I recommend finding something else. In our case we moved that code to what is now react router 7 but eventually all the react code we have will get replaced by Vue in some manner. We mostly moved away from react as a whole over time

DogPawHat 2y ago

Were you using auth in middleware?

abxyz 2y ago

I like NextJS and actively choose it for many projects. However, there is a big caveat: self-hosting NextJS is not the "real" NextJS experience that most people have because most people are using Vercel's platform and that is the focus of Vercel. Self-hosting NextJS is a bad idea, the benefits of NextJS are inextricably linked to the Vercel platform. You will live to regret self-hosting. I would never, ever consider doing it again and still suffer the pain of it day in day out because of a bad decision I made a few years ago. Use NextJS as expected (on Vercel's platform) or don't use it. If you self-host on your own serverless infrastructure, that's not a terrible idea, but if you try to self-host NextJS on servers, it will fall over at the first hint of traffic.

urbandw311er 2y ago
I’d like to understand more about why this is and whether your experience is universal.
- bodantogat 2y ago
  I’m curious too. I self host on a server, no issues so far.