11 ms·

This is what I'm referring to when I say BFF - https://remix.run/docs/en/main/guides/bff https://remix.run/docs/en/main/guides/bff Essentially, its the backend

This is what I'm referring to when I say BFF - https://remix.run/docs/en/main/guides/bff https://remix.run/docs/en/main/guides/bff Essentially, its the backend for frontend model, where I guess you really just have a node backend specifically for hosting your frontend app, so you get all of the advantages Remix/SSR/etc provide. The node server usually would handle auth between the frontend and the node backend with a cookie, and then the node backend would call your other backend services, either by forwarding the auth the frontend client sends, or transforming it into maybe a JWT token, or just mTLS? aka a glorified proxy server I guess.

dcre 3y ago
Ah. In that case, that is not a mode (which is why I misunderstood), that is the default way Remix works and it's more or less what every user of Remix is doing. Some people might implement API endpoints in Remix itself, but for the most part people are calling out to APIs in loaders. Here's a Remix site that works that way: https://rfd.shared.oxide.computer/ https://rfd.shared.oxide.computer/ We have an API written in Rust that serves the RFD contents and powers search. For logged-in internal users, we are also talking to GitHub APIs in loaders to pull in PR comments.
- JoshGlazebrook 3y ago
  Ah interesting. How do you generally handle auth between FE <--> Remix BE, and Remix BE <---> Other services? I could just keep my auth backend in go, on maybe like auth.mydomain.com, and issue cookies for .mydomain.com, which the remix BE can handle. This way the remix BE is really just a thin "api gateway" in a way.
  - dcre 3y ago
    We use cookie auth only for the Remix server. The API uses OAuth, or something close to it. So when a user logs in, we get a token from the API (scoped to the particular user, not a special backend super-token) and store it in the session (encrypted in the cookie value, Remix server has the key — this is built into Remix: https://remix.run/docs/en/main/utils/sessions https://remix.run/docs/en/main/utils/sessions). That token is then used by the Remix server whenever it talks to the API.

dcre 3y ago

Ah. In that case, that is not a mode (which is why I misunderstood), that is the default way Remix works and it's more or less what every user of Remix is doing. Some people might implement API endpoints in Remix itself, but for the most part people are calling out to APIs in loaders. Here's a Remix site that works that way: https://rfd.shared.oxide.computer/ https://rfd.shared.oxide.computer/ We have an API written in Rust that serves the RFD contents and powers search. For logged-in internal users, we are also talking to GitHub APIs in loaders to pull in PR comments.

JoshGlazebrook 3y ago
Ah interesting. How do you generally handle auth between FE <--> Remix BE, and Remix BE <---> Other services? I could just keep my auth backend in go, on maybe like auth.mydomain.com, and issue cookies for .mydomain.com, which the remix BE can handle. This way the remix BE is really just a thin "api gateway" in a way.
- dcre 3y ago
  We use cookie auth only for the Remix server. The API uses OAuth, or something close to it. So when a user logs in, we get a token from the API (scoped to the particular user, not a special backend super-token) and store it in the session (encrypted in the cookie value, Remix server has the key — this is built into Remix: https://remix.run/docs/en/main/utils/sessions https://remix.run/docs/en/main/utils/sessions). That token is then used by the Remix server whenever it talks to the API.