{"id":520415,"date":"2024-11-04T10:53:17","date_gmt":"2024-11-04T09:53:17","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=go&p=520415"},"modified":"2025-10-16T11:31:43","modified_gmt":"2025-10-16T10:31:43","slug":"create-a-full-stack-app-with-go-and-react","status":"publish","type":"go","link":"https:\/\/blog.jetbrains.com\/en\/go\/2024\/11\/04\/create-a-full-stack-app-with-go-and-react","title":{"rendered":"Create a Full-Stack App With Go and React"},"content":{"rendered":"\n

As a language that emerged over 14 years ago, Go has many use cases. From web development, APIs, and CLIs to Wasm, cloud technologies, and even AI-powered tools, its applications are broad. <\/p>\n\n\n\n

The same goes for demo projects, which have countless variations and purposes!<\/p>\n\n\n\n

Now, wouldn\u2019t it be great if there was a full-stack, API-oriented, and well-maintained demo project for Go? If you\u2019ve ever experienced a demo project fail during a live presentation, then you\u2019d certainly appreciate a more stable project! <\/p>\n\n\n\n

In this blog post, I\u2019ll walk you through the process of creating such a project \u2013 a full-stack app using Go and React.

Check out the source code here<\/a> to follow along.<\/p>\n\n\n\n

Introducing Go Eats<\/h2>\n\n\n\n

Go Eats is an open-source project similar to the food delivery apps you\u2019ve probably seen and used before. The project simulates the operations involved when placing an order in a real-world food delivery app.<\/p>\n\n\n\n

To build Go Eats, I used Go as the programming language, Postgres as the database, React for the frontend, and NATS for messaging. While Go is a good choice for these complex full-stack applications, finding demos can be challenging.<\/p>\n\n\n\n

I used GoLand<\/a> for this project because it takes care of setting up the Go SDK, installing packages, and much more straight out of the box.<\/p>\n\n\n\n

Let\u2019s take a closer look at the entry point of the source code: main.go<\/em>. <\/p>\n\n\n\n

This code initializes several services and handlers, establishes a database connection, loads environment variables, and sets up middleware, NATS, and the WebSocket.<\/p>\n\n\n\n

func main() {\n\t\/\/ load .env file\n\terr := godotenv.Load()\n\tif err != nil {\n\t\tlog.Fatal("Error loading .env file")\n\t}\n\n\tenv := os.Getenv("APP_ENV")\n\tdb := database.New()\n\t\/\/ Create Tables\n\tif err := db.Migrate(); err != nil {\n\t\tlog.Fatalf("Error migrating database: %s", err)\n\t}\n\n\t\/\/ Connect NATS\n\tnatServer, err := nats.NewNATS("nats:\/\/127.0.0.1:4222")\n\n\t\/\/ WebSocket Clients\n\twsClients := make(map[string]*websocket.Conn)\n\n\ts := handler.NewServer(db, true)\n\n\t\/\/ Initialize Validator\n\tvalidate := validator.New()\n\n\t\/\/ Middlewares List\n\tmiddlewares := []gin.HandlerFunc{middleware.AuthMiddleware()}\n\n\t\/\/ User\n\tuserService := usr.NewUserService(db, env)\n\tuser.NewUserHandler(s, "\/user", userService, validate)\n\n\t\/\/ Restaurant\n\trestaurantService := restro.NewRestaurantService(db, env)\n\trestaurant.NewRestaurantHandler(s, "\/restaurant", restaurantService)\n\n\t\/\/.... For the sake of brevity, the full code snippet is omitted here.\n\n\tlog.Fatal(s.Run())\n\n}<\/pre>\n\n\n\n
The journey<\/h2>\n\n\n\n
I started by working on backend tasks, such as creating APIs, before moving to the frontend. I chose Gin<\/a> as the framework to build these APIs.<\/p>\n\n\n\n
While I could have gone with Gorilla<\/a>, Echo<\/a>, Fiber<\/a>, or any other framework, I felt Gin would be a better choice for this project. It\u2019s more mature and stable, it\u2019s widely used, and it\u2019s also somewhat of a personal preference. <\/p>\n\n\n\n
Before selecting any framework, you should carefully consider the problem you are trying to solve or the specific business goal you are trying to achieve. Then weigh up the potential solutions and opt for the best one for your specific use case.<\/p>\n\n\n\n
The backend<\/h3>\n\n\n\n
While creating a demo app, it\u2019s important to ensure that the application is flexible enough to accommodate future changes and refactoring.<\/p>\n\n\n\n
For Go Eats, I implemented a service layer pattern, along with dependency injection<\/a>. Additionally, I utilized handlers for request and response communication with the service layer, which manages business logic and interacts with the database.<\/p>\n\n\n\n
\t\/\/ User\n\tuserService := usr.NewUserService(db, env)\n\tuser.NewUserHandler(s, "\/user", userService, validate)\n\n\t\/\/ Restaurant\n\trestaurantService := restro.NewRestaurantService(db, env)\n\trestaurant.NewRestaurantHandler(s, "\/restaurant", restaurantService)\n\n\t\/\/ Reviews\n\treviewService := review.NewReviewService(db, env)\n\trevw.NewReviewProtectedHandler(s, "\/review", reviewService, middlewares, validate)\n\n\t\/\/ Cart\n\tcartService := cart_order.NewCartService(db, env, natServer)\n\tcrt.NewCartHandler(s, "\/cart", cartService, middlewares, validate)<\/pre>\n\n\n\n
The project structure shown above ensures that the project is modular and flexible. Remember that creating too many nested directories can add unnecessary complexity. Especially if you\u2019re just starting your programming journey, it\u2019s best to focus on simplicity rather than going through multiple layers. Keep in mind that your code will inevitably need to be refactored at some point.<\/p>\n\n\n\n
The famous quote by Donald Knuth, \u201cPremature optimization is the root of all evil<\/em>,\u201d <\/em>feels particularly apt here.<\/p>\n\n\n\n
<\/p>\n\n\n\n
I did something similar for the database. I used the lightweight Bun<\/a> SQL client. <\/p>\n\n\n\n
However, I made sure that if I need to replace the ORM<\/a> in the future, my code will be able to adapt to the new changes based on the interface I have defined below.<\/p>\n\n\n\n
type Database interface {\n\tInsert(ctx context.Context, model any) (sql.Result, error)\n\tDelete(ctx context.Context, tableName string, filter Filter) (sql.Result, error)\n\tSelect(ctx context.Context, model any, columnName string, parameter any) error\n\tSelectAll(ctx context.Context, tableName string, model any) error\n\tSelectWithRelation(ctx context.Context, model any, relations []string, Condition Filter) error\n\tSelectWithMultipleFilter(ctx context.Context, model any, Condition Filter) error\n\tRaw(ctx context.Context, model any, query string, args ...interface{}) error\n\tUpdate(ctx context.Context, tableName string, Set Filter, Condition Filter) (sql.Result, error)\n\tCount(ctx context.Context, tableName string, ColumnExpression string, columnName string, parameter any) (int64, error)\n\tMigrate() error\n\tHealthCheck() bool\n\tClose() error\n}<\/pre>\n\n\n\n
This interface provides a blueprint for CRUD (create, read, update, and delete) operations and other common database interactions, ensuring that any struct<\/strong> implementing this interface can be used to perform these operations.<\/p>\n\n\n\n
GoLand keeps track of class implementation<\/a>, making navigation much smoother. <\/p>\n\n\n\n
To navigate to the implementation, press \u2318\u2325B \/ Ctrl+Alt+B<\/em>.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Most of the operations involve CRUD activities. I was also eager to experiment with server-sent events (SSE<\/a>) and WebSockets<\/a>, which I\u2019ve not explored much in the past. This project was a good use case for these technologies.<\/p>\n\n\n\n
Let\u2019s begin with SSE, a technology that enables the server to push notifications, messages, and events to clients over an HTTP connection.<\/p>\n\n\n\n
The code snippet below reads data from a JSON file and pushes the information so the client renders and displays the relevant data. <\/p>\n\n\n\n
func (s *AnnouncementHandler) flashNews(c *gin.Context) {\n\t_, cancel := context.WithTimeout(c.Request.Context(), 5*time.Second)\n\tdefer cancel()\n\n\tevents, err := s.service.FlashEvents()\n\tif err != nil {\n\t\tc.AbortWithStatusJSON(500, gin.H{"error": err.Error()})\n\t\treturn\n\t}\n\n\t\/\/ Set headers for SSE\n\tc.Header("Content-Type", "text\/event-stream")\n\tc.Header("Cache-Control", "no-cache")\n\tc.Header("Connection", "keep-alive")\n\n\tticker := time.NewTicker(6 * time.Second)\n\tdefer ticker.Stop()\n\n\teventIndex := 0\n\n\tfor {\n\t\tselect {\n\t\tcase <-ticker.C:\n\t\t\t\/\/ Send the current event\n\t\t\tevent := (*events)[eventIndex]\n\t\t\tc.SSEvent("message", event.Message)\n\t\t\tc.Writer.Flush()\n\n\t\t\t\/\/ Move to the next event\n\t\t\teventIndex = (eventIndex + 1) % len(*events)\n\t\tcase <-c.Request.Context().Done():\n\t\t\tticker.Stop()\n\t\t\treturn\n\t\t}\n\t}\n\n}<\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
WebSocket and NATS<\/h3>\n\n\n\n
Something else I’ve not worked with before but have always wanted to try is using WebSockets with the NATS messaging system. I evaluated these technologies as potential solutions for the project and ultimately decided to use them in the demo app.<\/p>\n\n\n\n
Here’s how the messaging process in the Go Eats app functions: <\/p>\n\n\n\n
Whenever a new order is created, a message is published to NATS informing the subscriber about the newly placed order.<\/p>\n\n\n\n
When the delivery person updates the order \u2013 whether it’s on the way, has failed, or has been delivered \u2013 the customer will receive this information in real time, a process that will be reflected in the UI.<\/p>\n\n\n\n
<\/p>\n\n\n\n
The code below defines the two topics:<\/p>\n\n\n\n