5 ms·

Have you ever considered that Next.js can simply be a layer only used by your web client that just consumes your API's? That or you can write API routes in Next

Have you ever considered that Next.js can simply be a layer only used by your web client that just consumes your API's? That or you can write API routes in Next.js yourself that can be used by your apps if you choose. I really don't understand the claim you're making when nothing about uses Next prohibits you from having an API. It is exactly what you say, an optimization/use case for web clients. But nothing about this prohibits other clients from doing their own thing consuming the exact same api's if you choose to do so.

nwienert 3y ago
Why would you choose then to have two completely different ways of managing data? It’s insanity. It’s like saying “you can totally use kubernetes to deploy your app and then later switch to swarm and support both!” (And even that analogy doesn’t capture the ridiculousness of doing this, as in that case you’re mostly changing higher level glue code, whereas with RSC your actual data management code would be totally different). Yea, technically you could, but why choose something far more complex that actually actively makes your app like experience worse? Apps want to handle data local-first, offline-first, with optimistic mutations, cached data between screens, instant animations with interactions between screens, etc. The ideal data model for this is something like firebase, parse, graphql, tinybase, etc. So now some bozo on your team bought into the hype and blindly wants to shove RSC into it and you’ve completely ruined the elegance of your stack. Instead of having a single codebase with a single abstraction for data fetching that’s clearly better than server-first, you now have two abstractions, and the server based one ruins all the things that make apps better than sites. It also doesn’t make anything faster for web. You can avoid shipping some JS without RSC, the React team just decided for some reason to couple avoiding sending parts of the tree with a whole new data fetching model, a complete self-own and big mistake. It’s no wonder Vercel the server selling company loves them.
- Jcampuzano2 3y ago
  But its not two "completely separate ways"? Your data management code is not completely different at all. If you want to, do it all in your API and next.js just calls through to it. And then call fetch in your components to the same API you would in a normal client app. The only difference is now those fetch calls happen on a server in RSC's or w/e rather than from the client directly. I'm honestly not even arguing for the hype since I don't use Next.js myself for any production projects at this time, I was simply pointing out that its not as if choosing to use it automatically means you can't use an API which is what the grandparent makes it seem like with their rant about still needing an API. There are some teams that truly do want a server rendered app that Next.js provides as well as other features. They can use it for that if they so choose. I'm honestly not even arguing RSC's are better or not because I know there are tradeoffs on both ends and we don't use them ourselves at where I work. Like I said, I was just poiting out it isn't a simple one or the other. There are plenty of teams out there that use a backend for frontend architecture that basically is a data transformation layer for their API to clients. For your web stack that could be next.js.
  - SlickStef11 3y ago
    For those that want to read up on the BFF pattern: https://bff-patterns.com/ https://bff-patterns.com/

nwienert 3y ago

Why would you choose then to have two completely different ways of managing data? It’s insanity. It’s like saying “you can totally use kubernetes to deploy your app and then later switch to swarm and support both!” (And even that analogy doesn’t capture the ridiculousness of doing this, as in that case you’re mostly changing higher level glue code, whereas with RSC your actual data management code would be totally different). Yea, technically you could, but why choose something far more complex that actually actively makes your app like experience worse? Apps want to handle data local-first, offline-first, with optimistic mutations, cached data between screens, instant animations with interactions between screens, etc. The ideal data model for this is something like firebase, parse, graphql, tinybase, etc. So now some bozo on your team bought into the hype and blindly wants to shove RSC into it and you’ve completely ruined the elegance of your stack. Instead of having a single codebase with a single abstraction for data fetching that’s clearly better than server-first, you now have two abstractions, and the server based one ruins all the things that make apps better than sites. It also doesn’t make anything faster for web. You can avoid shipping some JS without RSC, the React team just decided for some reason to couple avoiding sending parts of the tree with a whole new data fetching model, a complete self-own and big mistake. It’s no wonder Vercel the server selling company loves them.

Jcampuzano2 3y ago
But its not two "completely separate ways"? Your data management code is not completely different at all. If you want to, do it all in your API and next.js just calls through to it. And then call fetch in your components to the same API you would in a normal client app. The only difference is now those fetch calls happen on a server in RSC's or w/e rather than from the client directly. I'm honestly not even arguing for the hype since I don't use Next.js myself for any production projects at this time, I was simply pointing out that its not as if choosing to use it automatically means you can't use an API which is what the grandparent makes it seem like with their rant about still needing an API. There are some teams that truly do want a server rendered app that Next.js provides as well as other features. They can use it for that if they so choose. I'm honestly not even arguing RSC's are better or not because I know there are tradeoffs on both ends and we don't use them ourselves at where I work. Like I said, I was just poiting out it isn't a simple one or the other. There are plenty of teams out there that use a backend for frontend architecture that basically is a data transformation layer for their API to clients. For your web stack that could be next.js.
- SlickStef11 3y ago
  For those that want to read up on the BFF pattern: https://bff-patterns.com/ https://bff-patterns.com/