Hi all, As part of the effort to rewrite the Synapse mediation engine in Go, I have been exploring suitable HTTP routing packages to handle the core routing functionalities. The key requirements identified for this include:
1. Support for method-specific routing (e.g., GET, POST). 2. Ability to define sub-routes for better organization. 3. Middleware support for request processing pipelines. 4. Extraction of path variables from request URLs. 5. Parsing and handling of query parameters. In addition to routing, we need a robust library to implement Cross-Origin Resource Sharing (CORS) for our new API endpoints. I have evaluated several Go CORS packages, including github.com/rs/cors, github.com/gorilla/handlers, and github.com/gin-contrib/cors. - github.com/gorilla/handlers provides a comprehensive set of HTTP handlers, including CORS. While robust, it might introduce more dependencies than strictly necessary for just CORS functionality. - github.com/gin-contrib/cors offers CORS middleware specifically designed for the Gin framework. Since we are still evaluating our primary routing package, tightly coupling our CORS implementation to a specific framework might limit our flexibility. After considering these options, I have selected the github.com/rs/cors package. This library stands out due to its focused nature, providing a clean and highly configurable way to handle CORS. It offers granular control over allowed origins, methods, headers, and credentials. Its middleware-based approach makes it easily integrable with any net/http <https://pkg.go.dev/net/http> compatible handler, offering excellent flexibility regardless of our final routing package choice. For the main HTTP routing, I considered various popular Go packages. Some notable ones include Gin, Echo, and Chi, alongside the built-in net/http <https://pkg.go.dev/net/http> package. These packages offer different levels of abstraction and features. - Gin <https://pkg.go.dev/github.com/gin-gonic/gin> is known for its high performance and rich feature set, including middleware, JSON validation, and rendering. Benchmarks often show Gin performing well in request handling speed. - Echo <https://github.com/labstack/echo> emphasizes developer-friendliness and extensibility, with features like automatic TLS, data binding, and middleware support. It also generally exhibits good performance. - Chi <https://github.com/go-chi/chi> is a lightweight router focused on composability and idiomatic Go usage, aligning closely with the standard net/http <https://pkg.go.dev/net/http> handlers. It's known for its speed and simplicity. While these packages offer compelling features and performance, the standard net/http <https://pkg.go.dev/net/http> package provides a solid foundation and meets all our core requirements. It inherently supports method routing through handler registration for specific methods. Sub-routing can be achieved through handler prefixes and custom logic. Middleware can be implemented using handler wrappers. Path variables and query parameters are accessible through the r.URL.Path and r.URL.Query() methods respectively. Performance-wise, while third-party routers often introduce optimizations for specific use cases, net/http <https://pkg.go.dev/net/http> is the bedrock upon which these are built and is inherently efficient. For instance, Go's standard library has undergone significant performance improvements over time, making net/http <https://pkg.go.dev/net/http> a competitive option. While specific benchmark numbers can vary based on the test setup, the overhead of net/http <https://pkg.go.dev/net/http> is generally minimal. Moreover, its stability and long-term maintenance are guaranteed as it is part of the core Go language. This reduces the risk of future migrations due to library obsolescence. Considering the reliability, long-term support, and the fact that net/http <https://pkg.go.dev/net/http> directly addresses all our essential routing needs, I propose we utilize the standard net/http <https://pkg.go.dev/net/http> package for our routing implementation. Coupled with the github.com/rs/cors package for robust CORS support, this combination offers a stable, performant, and flexible solution for our requirements. I am open to any suggestions or alternative perspectives on this choice. Please let me know if you have any thoughts or concerns. -- Thisara Rathnayaka Undergraduate Student | Computer Science & Engineering University of Moratuwa LinkedIn <http://www.linkedin.com/in/weerakoon-thisara-rathnayaka-881826177> | GitHub <https://github.com/ThisaraWeerakoon> | Blog <https://medium.com/@thisara.weerakoon2001>
