3 ms·

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

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/

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/