4 ms·

It depends. If you do server-side rendering with something like nextjs, then its quite a lot of code. With trpc you can share types without going through an i

by spion 4y ago

It depends. If you do server-side rendering with something like nextjs, then its quite a lot of code. With trpc you can share types without going through an intermediary schema language (https://trpc.io/ https://trpc.io/) although I think it would've still benefitted from separating the schema from the implementation (hope you don't forget the type specifier and import your backend into your frontend by accident) For business logic as always the anwwer is "it depends". Does your app benefit from zero-latency business logic updates? Do you need rich "work offline" functionality combined with a rich "run automation while I'm away" for the same processes? etc.

AgentME 4y ago
Even when using Nextjs, it's still pretty common to have a separate API backend that doesn't also have to be in Javascript/Node. There are parts of backend code (HTML generation) that very strongly benefit from being unified with the frontend code, and there are parts of backend code (like database persistence code) that much less strongly if at all in some cases benefit from unification with the frontend code. Many people split these parts of backend code up between a separate Nextjs backend service and API backend service, and Nextjs lends itself well to this. I'm a big Nextjs fan; I just think it's useful to emphasize that using it doesn't necessarily have to mean "only javascript/typescript on the backend".
- chrisweekly 4y ago
  This. I like how the Remix.run devs frame the "BFF" (Backend-For-Frontend) pattern: https://remix.run/docs/en/v1/guides/bff https://remix.run/docs/en/v1/guides/bff
  - mwcampbell 4y ago
    That document starts with this: > While Remix can serve as your fullstack application, Isn't that where most teams should start, and where they should stay unless they have a really good reason to get more complicated? This is what I was thinking of while reading the GP comment about Next.js.
    - chrisweekly 4y ago
      For greenfield projects, yes. But for projects where there's already a decent backend API, it's a reasonable approach to use Remix "only" as a BFF.

by spion 4y ago

AgentME 4y ago

Even when using Nextjs, it's still pretty common to have a separate API backend that doesn't also have to be in Javascript/Node. There are parts of backend code (HTML generation) that very strongly benefit from being unified with the frontend code, and there are parts of backend code (like database persistence code) that much less strongly if at all in some cases benefit from unification with the frontend code. Many people split these parts of backend code up between a separate Nextjs backend service and API backend service, and Nextjs lends itself well to this. I'm a big Nextjs fan; I just think it's useful to emphasize that using it doesn't necessarily have to mean "only javascript/typescript on the backend".

chrisweekly 4y ago
This. I like how the Remix.run devs frame the "BFF" (Backend-For-Frontend) pattern: https://remix.run/docs/en/v1/guides/bff https://remix.run/docs/en/v1/guides/bff
- mwcampbell 4y ago
  That document starts with this: > While Remix can serve as your fullstack application, Isn't that where most teams should start, and where they should stay unless they have a really good reason to get more complicated? This is what I was thinking of while reading the GP comment about Next.js.
  - chrisweekly 4y ago
    For greenfield projects, yes. But for projects where there's already a decent backend API, it's a reasonable approach to use Remix "only" as a BFF.