NextJS - Great Choice for Startups

i'm not available to meet today there's a lot to unpack here i'll respond later

Lets break it down a little bit

1. Your task is not to choose or decide if next/prisma/etc. Is correct. This is something i already stated yesterday. You dont need to figure out or refute a decision I already made
2. Your task is to list the required server services derived from the mvp requirements: auth, onboarding, orders, role management...

After you list those, you can proceed to determine the entities and relations we would use and list their fields

3. If your interested in why i made architecture decisions in regard to the tech stack we can discuss that on Monday, but its completely irrelevant to your task
4. In regards to using powerful instruments, Let's say you need to build a house... you naively ask me for a hammer, not knowing what type of hammer your going to need. and i bring you an entire toolset, with multiple hammers in different sizes.

Are you going to use ALL the hammers to hit 1 pin? Or are you going to take the most familiar one your comfortable with and hit the pin in front of you once?

That's right, you dont need to be an expert in NextJS to return a jsx component, you just need to be familiar enough to get the job done quickly.

That's a common approach in small startups, especially if your inexperienced. Nobody expects you to be a principle engineer to start writing code, its ok to learn as you go

What technologies would you choose instead? and how many days/weeks would it take compared to 2-3 weeks?

It will take you 3 weeks longer to achieve the same result with tools that perform the same just because the syntax is different?😕

fullstack development and ssr are not new principles and are definitely not invented only in the last 2 years, these concepts also didn't become popular in the last couple of years, they are in fact very very very old and not a passing trend.

It's story time 🙂
it all started in the server

Let's go back in time, into the beginning of the web (www) in 1990. Things were in chaos. There were a lot of protocols that didn't exist yet, everything was uncharted territory at the time.

IP routing protocols were not what they are today, and the physical lines of the internet were also not nearly as fast and even the communication layer was still in development;
http v1 only came out in 1991
and html first came in 93

In certain aspects things were simpler back then: a server was just a pc that could host a domain and return a string. that string later became an html string, and later entire files were compressed and streamed. there was a markup (.html), styling (.css) and lastly some client side code (.js) but javascript was invented in 95, and started to wide spread after 97.

So everything was sent via the server, it was a monolith, and it handled html rendering and everything else in the server side. The concept of Server Side Rendering (ssr) also known back then as Server-side scripting was first mentioned in the early 90s, the same dude who invented javascript also released ssr support for javascript in 94

this fullstack approach continued and sticked since the beginning of web development. note how popular php was back in the day, php also came out in 95 and it was HUGE back then and up to this day. ruby on rails also came out in 2004 and laravel came out in 2011 all are fullstack frameworks with ssr

next.js is technically 13 years old (npm first released in 2011) but it became a react framework with ssr support only in 2017

client side started to offload some work from the server

the concept of client side rendering and single page application was invented in 2002 and implemented in 2006 with AJAX.

this was also when the client-server separation model started becoming more and more popular. when frontend development started becoming more important and more complicated, you could do a lot more on the client side and improve the user experience while reducing server side cost.

entire teams were dispatched and were only focused on frontend development, up until then the industry didn't consider frontend developers seriously.
now that client side involved writing sophisticated code in addition to markup, styling and many more shitty but necessary concerns, things were different. web applications started to be responsive.

react first came out in 2012, and became popular in 2015
angular first came out in 2010
and vue was first released in 2014

React dominated Frontend but SPA was limiting

soon after react (which is a library, not a framework) became popular, it was evident that it had its limits.
many developers coming from ruby on rails, laravel, django and other communities familiar with multipage application frameworks started to come into the react domain and started bringing their development approach with them.
hence many additional open source libraries were developed to complete the missing react features.

The rise of NextJS The production Framework for React

NextJS is one example for a complete framework for react,
giving you many missing supporting features that can compete with other javascript frameworks.

although NextJS has awesome features like SSR and SSG, its actually not required to know them at all to get working with nextJS, if you know React, you know Next, and if you run into something that React can't give you, that's where Next comes into play.

since Next first came out, it became more and more popular, by 2020 it was clear that react frameworks were industry standards, and Next was the leading react framework and continued to do so until today

The benefits of Fullstack Development

while its true that separating concerns does not only apply to software, but also to people. when you start a new project and you manage a small team, being able to switch freely from server to client development and being able to work on the entire stack will produce more speed and less friction. this concept is amplified when your in a startup.

having 1 framework that seamlessly connect both client and server side means less work on the communication between them, less things to learn and less things to worry about.

adding automatic type safety and validation with tRPC to NextJS saves you a lot of contracting trouble and code duplication: less work -> get things done faster.

Architecture Decision making

losing the benefits of fullstack development is not worth the cost even if we would have needed to subtract a 3 weeks time towards a learning curve.
hence separating our project to something like nest & react makes less sense,
you'll need more work for writing contracts & validations and end up with less power in your fingertips.

you also need to consider the learning curve of other developers when comparing something like nest to next. nest has an object oriented approach which requires the developers working on the project to be familiar with more coding concepts that are frankly, not required to run a server request. most javascript developers are coming with more of a functional programing approach, from things like express or fastify. this is relevant for any future developer who will work on the project.

there's also community to consider when comparing nest to next, nextJS is consistently x2 times more popular than nestJS (3m vs 6m weekly downloads), which means more people are familiar with Next. this is important not only because you get a bigger support group, but also because one day all of us will probably be replaced by other people and statistically speaking, these other people will be more familiar with NextJS. while I'm aware of the fact that in many russian and ukraine forum circles nestJS is widely popular, it is in fact less so when looking outside of those circles.

since you already have someone who is an expert in NextJS in your team,
who is also active in NextJS groups,
and has already created a working project for you with working code examples,
it makes even less sense to bake on something else because of a lack of syntax familiarity

there is actually more that can be said here but...

to conclude, although i enjoy Architecture Decision making discussions, we also need to tend to the amount of time it takes to properly explain such decisions, hence some decisions are simply pre-made and should probably stay that way out of lack of time. making these long explanations would only cost whoever pays me on the clock but bring no observable business value to that person.

A final note is that as you can probably see, making some of these decisions is very hard, and it would be unreasonable to expect someone without many years of specific experience to make them, and therefore they are made for them.

usually when software developers start their journey, they learn 1 or 2 ways a accomplish a task and they might become biased towards that framework, language, pattern etc. but as you become more familiar with different things your bias might change, in your personal development journey, it will benefit your progress to be familiar with several (not too many) ways to accomplish your task.