Go is a fancinating language for building backend service, while React is a modern framework for building frontend web app. I would like to share my experience on how you can put this two together to build a full stack web app.

The structure

The chance is you probably can find a template on github and develop your app based on that. But I recommend you pause for a second and think about the structure of the codebase. There are basically two options:

Option 1: Let Go serve the frontend

The idea is to generate the frontend static files and put them in a folder, then let Go serve the static files. It is simple and straightforward. The only thing you need to keep in mind is this is in essence a monolithic app, which means you can’t scale the frontend and backend separately.

Option 2: Using reverse proxy

The idea is to use a reverse proxy to serve the frontend and backend separately. The reverse proxy will forward the requests to the backend or frontend based on the url path. This is a more flexible approach, as you can scale the frontend and backend separately. The downside is that you need to setup a reverse proxy, which is not that difficult, but still an extra step.

Using which option is up to the scale expectation of your app. Yes you can always start with option 1 and build some quick prototypes, however if you are having option 2 in mind, you can at least keep the frontend stuff clean in case you would switch to option 2 later.

The API framework

The backend is mostly about providing some APIs for the frontend to call. There are many options for the backend framework, such as Gin, Echo, Beego, etc. However I would say do you really need a complet framework for rest apis? Yes these battery included frameworks make building rest apis much easier. however it also sacrifices the flexibility. e.g. if you want to start the api server along side with a daemon process, you will find it not that easy to play around.

I personally don’t like to be tired to a framework so I prefer to use some API libraries like gorilla/mux, it only provides the basic routing and request handling, and you can build your own middleware and handlers on top of it.

ORM or not

If you are a minimalist go developer, you probably would not like the ideas of ORM, which brings too much “candy” to the pure go code. I was one of them, then I found myself writing a lot of not so interesting code to handle the mapping between the database schema and data model. Until I found libraris like GORM which in essence is a much standard way of the same stuff I was doing. So I got it I was in fact reinventing the wheel. Perhaps I would miss some flexibilities , but as far as I can see, ORM would be here to stay.

The frontend framework

The morden frontend frameworks are just too many to choose from. I only have production experice of React so I would go with it. The framework I have used before is Next.js, I have used it to build a full stack prototype and I would say it is quite handy. But since I am using Go as backend, I decided to use a lighter framework like Vite. The reason is I only need an effiecient build tool to compile the react code to static files, no fancy stuff like server side rendering . Vite is like its name implies a very fast build tool, I find it’s a good companion for Go which is also fast.

Build and deploy

With the structure option 1 , the building and deployment is quite straightforward. You only need to first build the frontend into static file , configuring the route to serve the static files, then build the backend and deploy it to single machine or using docker.

With the structure option 2, you need to build the frontend and backend separately, then deploy them to different machines or docker containers. You also need to setup a reverse proxy to forward the requests to the backend or frontend based on the url path. Yes you can put all these in one machine/docker container, but what is its differnce from option 1 then?

Some thoughts

This is my practice on how to build a go+react(vite) web app. I believe there are other perhaps better ways to do it. However I decide to start working on what I know that just works. It’s I think the eternal dilemma on exploration and exploitation especially at a time when so many new stuff coming out. maybe you will never reach a perfect balance, but people who move fast seems always have a better chance to shine.