They’re both on subdomains in my instance - so app.example.com and api.example.com. For another project, I have deployed this architecture to a single server via Laravel Forge. The Remix web app is available at the root domain via an nginx reverse proxy to port 3000. The Laravel backend is only accessible over localhost on that server so the Remix backend makes calls to localhost:8000 on that same server. That works fine for smaller projects where you don’t need to access the Laravel backend outside of the Remix backend.

Hi Jaska , I'm sorry if the article wasn't clear! The examples in this article of Remix talking to the database directly were how I did things before adding the Laravel backend. Now the all the Remix loaders do is call the API for my Laravel backend. So I only write the backend code once for exactly the reasons you mentioned. Hopefully that clears things up!

I actually extracted this into its own npm package: https://github.com/davecalnan/typesafe-api/tree/main/packages/typesafe-api-client yarn add @davekit/typesafe-api-client It's basically just: export const api = createApiClient({ baseUrl: "https://your-app.com/api" }); const result = api.get( "/some-path" ); const onClick = () => api.delete( "/some-other-path" ); I pair it with @davekit/typesafe-api and generate types for all my backend routes that I can then import into the frontend and get type-safety over the API. But that needs a whole blog post of its own to get into.

Route::view() is great! I also really like closures for simple stuff just like that e.g. a health check endpoint that just needs to return a 200 OK. In my actual controllers I would paginate and use Form Requests/JSON Resources, authorisation etc - just wanted to keep that example simple and comparable to the Prisma one!