Is the need for a traditional backend gone now?

[dan-cooke]

So I've been blown away by my initial investigations into Remix. The post on Remix vs Next is what initially brought me here.

I'm so blown away infact, that I'm in the proces of completely refactoring my app (3 years of nextJS and apollo-client) into a Remix application.

But before I begin the work, I am a bit torn when it comes to my backend api package. So my question is:

What are the pros and cons of maintaining a seperate API package when you can just connect to your DB from your remix server?

Here are the list I have come up with, I would be very interested in hearing some other opinions on the matter.

Pros of a seperate API Package:

• Seperation of concerns - code is tidier, I can just focus on the UI stuff without thinking about my backend code.
• More nimble for deploying just the API.. If you have external clients that need to connect to the API, you don't need to rebuild the entire UI for a small API change

Cons of a seperate API Package:

• Shared libraries are required if you need to share code between the UI and API
• Slower - we are adding a middleman between the remix server and the database, when we could just connect from the remix server directly.
• Seperate infrastructure requirements to the UI, more setup and maintenance to get it deployed. And its essentially going to be running on a node server somewhere anyway.

So thus far.. i am leaning towards ditching my API package, and making db requests directly inside my UI server, thoughts?

[sergiodxa]

Keeping the DB access in the Remix app is probably going to be faster, but now it means you need to use JS for your business logic code.

Keeping an API server means you could use something else to build your API, for example use Rails or Django or Laravel, or some compiled language like Go or Rust or Java. This can be useful if you have a team of BE developers using another language or framework so they can use the one they know the most and your Remix app can fetch that API.

Usually, server to server requests are going to be faster than a client to server, your servers (Remix and your API) could even be physically on the same server making the latency in their communication almost 0, even if it's not it's usually way better than the latency between the browser and the server and you can control it and try to reduce it.

Another benefit of using an external API could be if you want to build a mobile app, then you need an API and you may need to scale it independently of the Remix app, so you could build the API as a separate service (using JS or not), of course you can use Resource Routes to build the API as part of Remix too.

Also, if the API is in another language then the shared libraries are not going to be an issue anymore because you just can't share code between them.

Another benefit is that BE frameworks comes with some features that Remix, so far, doesn't have, things like an ORM (in Remix you bring your own, most likely Prisma), a job queue system, maybe a mailer, probably authentication and authorization features, and more things I don't remember. If you use Remix alone you will need to add all of those things yourself to your app, so using a framework will give you a fast start.

---

At the end, separating an app in two services one for the FE and another for the BE is most probably an organizational thing than a technical thing, because technically speaking a single server is probably going to be faster because you don't add a network layer in the middle, except you go with serverless for the scaleability in which case you add the network layer and make everything a little bit slower in exchange of scale.

[dan-cooke]

Some great points here. Thank you!

Another benefit of using an external API could be if you want to build a mobile app, then you need an API and you may need to scale it independently of the Remix app, so you could build the API as a separate service (using JS or not), of course you can use Resource Routes to build the API as part of Remix too.

This is one of my main considerations. One soluttion would be to extract database access logic into a shared library that could be consumed by both my Remix FE server and additionally a mobile API server if required in future. Or Resource Routes as you mentioned :)

separating an app in two services one for the FE and another for the BE is most probably an organizational thing than a technical thing,

Yep, my thoughts exactly.