4 ms·
We used NextJS on a couple of projects where I work and are already phasing them out. The reasons are manifold, but a few key factors: * difficult auth story.
by twodave 1y ago
We used NextJS on a couple of projects where I work and are already phasing them out. The reasons are manifold, but a few key factors:
* difficult auth story. next-auth is limited in a few ways that drove us to use iron-session, such as not being able to use a dynamic identity provider domain (we have some gov clients who require us to use a special domain). This required us to basically own the whole openid flow, which is possible but definitely time we didn’t expect to have to spend in a supposedly mature framework.
* because the NextJS server wasn’t our primary API gateway we ended up having to proxy all requests through it just to add an access token to avoid exposing it on the client. The docs around this were not very clear, and this adds yet another hop with random gotchas like request timeout/max header size/etc.
* the framework is very aggressive about getting you on their cloud, and they make decisions accordingly. This was at odds with our goals.
* the maintainers aren’t particularly helpful. While on its own this would be easy to look past, there are other tools/frameworks we use in spite of their flaws because the maintainers are so accessible and helpful (shout out to Chillicream/HotChocolate!)
- vdfs 1y agoWhat did you move to? We've been using NextJS as a frontend with somehelpful server-side/api handling, but the backend is done in Django. We are basically just using ReactJS with the convenience of NextJS (like file based routing)
- t-writescode 1y agoNot OP; but when I was thinking about using Next.JS, and doing a deep investigation, I came to the decision that, for server-side rendering, I'm quite happy to use Kotlin and Ktor (my backend is also Kotlin - I have a lot of client-types, which is why they're separate), and I've been quite happy with Ktor's html dsl + htmx for speed. And Kotlin + Ktor feels very good to write in on serverside. Fast, easy and fluent to write in, like Ruby; but with Java's ecosystem, speed and types.
- catgirlinspace 1y agoHow are you doing reusable components with the html dsl? From the little bit I’ve tried ktor this was something I could not figure out and it kinda just pushed me away since I couldn’t find anything.
- t-writescode 1y agoTo build reusable components, I end up using a mix of a lot of extension functions and Kotlin's function pointer syntax. So, the components themselves will look something like this: fun HtmlBlockTag.radioButtonWithLabel( groupName: String, id: String, hidden: Boolean = false, radioButtonFunc: (INPUT.() -> Unit)? = null, func: LABEL.() -> Unit ) { radioInput(name=groupName) { this.id = id this.hidden = hidden radioButtonFunc?.invoke(this) } label { this.htmlFor = id; func() } } And then use of them will be like this: call.respondHtml { body { div(CSS_CLASS_NAME) { radioButtonWIthLabel(MORE_CSS_CLASS_NAME, "group", "id") { +"Text for the label" } } } } More complicated examples just extend that quite a lot. I've also got whole files dedicated to single extension functions that end up being a whole section that I can place anywhere. --- And then to test those single-function components, I'll do something like this: class SingleSectionTest { private suspend fun ApplicationTestBuilder.buildApplicationAndCall( data: DataUsedForSection ): Document { application { routing { get("test") { call.respondHtml { body { renderSingleSection(data) } } } } } val response = client.get("test") val body = Jsoup.parse(response.bodyAsText()) return body; } @Test fun `simple test case`() = testApplication { val data = DataUsedForSection("a", "b", "c") val body = buildApplicationAndCall(data) // all the asserts } } And so on. Is this what you were wondering? Or would you like a different sort of example?
- catgirlinspace 1y ago
- twodave 1y agoWe have some other projects that are Angular, and NextJS was sort of a proof of concept for us. The goal is to just have one front-end framework for our devs to work with (and keep up to date, ugh!), so we’re folding those deploys back into our Angular family of features.
- TranquilMarmot 1y agoHave you checked out https://astro.build/ https://astro.build/ yet? You can drop in any framework where you need it, so if you need to bring along those Angular components you can but you can also lean on React if you need it.
- twodave 1y agoNo, and on a cursory look it doesn’t seem very aligned with our goals anyhow.
- TranquilMarmot 1y agoI like Remix a lot better for this use case than Next.js. Much simpler, easier to host on your own servers. Astro is also really nice and easy to learn and host.