I'm developing a simple RESTful API using Go's Goji framework (although this question is language-agnostic), in which parameters from the URL are queried against a PostgreSQL database. Here's how it works:
First we define a struct that holds a reference to our ORM
This struct contains an Init
method that allows us to initialize a connection. This struct contains other methods to handle HTTP requests and exists primarily as a means to associate the database with the request handler.
type Context struct {
db *gorm.DB
}
func (ctx Context) Init(user string, name string) (Context, error) {
db, err := gorm.Open(
"postgres",
fmt.Sprintf("port=5432 sslmode=require host=domain.xxx"),
)
ctx.db = &db
return ctx, err
}
func (ctx Context) handleGetRequest(c web.C, w http.ResponseWriter, r *http.Request) {
// ... business logic
}
This structure is then initialized exatly once when the web application starts up
With this architecture, any database failure implies that the web app must be restarted.
func main() {
// "Context" is a means of including a DB object with route handlers
ctx, err := context.Context{}.Init(dbuser, dbname)
if err != nil {
panic(err)
}
defer ctx.Close()
// do other stuff, e.g. set up routing and whatnot ...
}
My questions are as follows:
- From a software architecture point of view, what is a reasonable approach for gracefully handling database downtime and automatically reconnecting when the DB becomes available?
- How can I work the recommendations in this answer into my design?
tl;dr: what's the industry standard for handing DB failures within web applications, from a software architecture perspective?
Aucun commentaire:
Enregistrer un commentaire