Is it good practice to dockerize your react frontend independently from your backend?

user_377044 0
Viewed 213

I am about to deploy a react app. I have an API for my react app. On a react development server, it serves react on port 3000, and my API is on port 4000.

I see two ways of going about this.

One way is to use CORS in development. If we go this route, we'll need to also use CORS in production. We'll have an ENV file which tells the react app which host/port it should make requests to. Our CI pipeline will have 2 docker containers, 2 repos. When we deploy a frontend or a backend change, we'll be able to restart both servers independently. We'll have 1 docker running on mysite.com and the api running on api.mysite.com.

Another approach is to use the proxy in package.json and forward all requests to our backend. i.e. instead of having to make requests to localhost:4000/sign-in we just make requests to /sign-in. With this approach, I think it makes a lot of sense to use a monorepo. We would have

app
  api/
    my-api
  ui/
    my-react-app

My api would be mostly RESTful routes, but would have a catch all for all non-api routes that would serve an HTML file which would serve the javascript. The CI pipeline would build and minizmie and push the JS to S3 and give it a name such as {SHA1}.min.js and our API's index.html file would have

<script src=`{SHA1}.min.js`></script>

I can't seem to make up my mind as to the better approach. Will it be simpler to be able to independently deploy the frontend vs backend? Is it unnecessary to have a docker that only serves a single html file ? Which path should we take ?

docker reactjs
1 Answers

Note: This question has no correct answer (or may have more than one): it depends on your environment and your experience.

During your app build, not only the JS might change. Maybe you change your favicon, or the installable logo or some other details from your manifest, or some other assets, like CSS. So, deploying the frontend is not just deploying the JS to S3 and changing the SHA in the initial HTML.

Besides that, your statics can be served very fast with a basic NGinx/Apache (maybe behind a CDN). But your backend probably needs to make some calculations, access some DB or some data files from the hard disk. This is a different way to work, so splitting both deploys IS a good idea. It also allows to scale differently on demand.

Whether you use a single ingress (1 domain) or split it into two (2 domains), I think is just a matter of what you feel more comfortable with and your scale approaches. It's not very different to access api.yoursite.com/ or yoursite.com/api/ from the frontend.

  • Using The same domain, catch the /api/ requests to proxy them to the backend. The rest of requests are served directly or proxied to a second webserver with the statics. If only proxies stuff, you can use HAProxy or Træffick instead, which will probably perform better than NGinx or Apache.
  • Using different domains allows to remove the first proxy, which is very fast/cheap, but might allow to scale up differently (for example, adding more public IPs to api.yoursite.com for a -slow- scale up).

As you can see, there are several variables: for example, it's very different deploying to a single server using docker-compose, to a Kubernetes cluster or to an autoscaling group at AWS. It's also very different if you expect to receive 100 visits per day than having to handle billions of active users heavily accessing your DB.

user_29281680
Related