4 ms·
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
by 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 agoAh 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 agoWe 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.