Yeah, I do the same. Most of what I do is Next.js + a good bunch of npm packages to get the "full stack". But I wouldn't call Next.js full stack because it can do SSR, or even API routes. But again, that's just me confused about what is "full stack".
> But again, that's just me confused about what is "full stack".
There term has definitely become more amorphous and ambiguous. I spent a few years mostly working with physical hardware, networking, virtualization, scripting deploys for DBs and OSs, and handling the DNS alongside some business oriented C#. Then I moved over to working with AWS and Azure.
Now I primarily work with Node, Golang and Python.
With modern tooling and a team that supports it, I've found myself mostly working on services, APIs and React front-ends. Even with Next.js, it's hard to know where the line on what "full stack" is.
It's sort of come to encompass the frontend and backend of an application, less so the architecture of it. Mentally, however, I still lump it all together when I think of what qualifies for "full stack", as I personally think the term represents an understanding of how everything works together, which definitely helps when troubleshooting the source of a problem.
Yeah - I really hate the term "full stack" as it can really mean vastly stuff in different contexts, between different companies, hell - even in leading teams I feel like I have to nail down what "full stack" means between the members.
> But again, that's just me confused about what is "full stack"
Me too because it's grown into an amorphous definition =/
