3 ms·

It'll depend on what you're building, but there's some value in rendering React on our backend. For example, we render documents (HTML => PDF) and emails with t

It'll depend on what you're building, but there's some value in rendering React on our backend. For example, we render documents (HTML => PDF) and emails with the same React components we use for our frontend to keep styling consistent. There are also some utils we use (in similar contexts) on both sides largely for things like string formatting or annoying math. Not a ton of stuff, but it's nice to have one bulletproof util to format phone numbers in every context. Another one is payment fee calculation[0], so we can guarantee the user sees the same number they'll be charged. I think the more powerful benefits are definitely hiring and having a team that can work on both sides (and in that regard I think your points are perfectly reasonable), but there are definitely some more direct benefits in our case. [0]https://support.stripe.com/questions/passing-the-stripe-fee-on-to-customers https://support.stripe.com/questions/passing-the-stripe-fee-...

peferron 6y ago
I wasn't very clear with my earlier description; the frontend is a SPA served by Node.js, while the backend is a completely separate GraphQL API service which I'm considering to rewrite in Clojure. So the frontend can actually do SSR to render PDFs or emails. However, it would definitely be much harder to to ensure that any phone formatting or fee calculation done directly in the user's browser matches what the API returns. So yeah, definite benefits in sharing a language there. Thanks for the examples!
- rdgthree 6y ago
  Makes sense! We have the same setup. FWIW, it's nice to do the React rendering on the backend because it's a bit easier to pass values to those templates directly (as opposed to using URL params or something). We render the React to a string there, then just pass that HTML string to a Browserless[0] instance. Certainly not a showstopper though, passing a URI is easy enough! [0]https://docs.browserless.io/docs/pdf.html https://docs.browserless.io/docs/pdf.html

peferron 6y ago

I wasn't very clear with my earlier description; the frontend is a SPA served by Node.js, while the backend is a completely separate GraphQL API service which I'm considering to rewrite in Clojure. So the frontend can actually do SSR to render PDFs or emails. However, it would definitely be much harder to to ensure that any phone formatting or fee calculation done directly in the user's browser matches what the API returns. So yeah, definite benefits in sharing a language there. Thanks for the examples!

rdgthree 6y ago
Makes sense! We have the same setup. FWIW, it's nice to do the React rendering on the backend because it's a bit easier to pass values to those templates directly (as opposed to using URL params or something). We render the React to a string there, then just pass that HTML string to a Browserless[0] instance. Certainly not a showstopper though, passing a URI is easy enough! [0]https://docs.browserless.io/docs/pdf.html https://docs.browserless.io/docs/pdf.html