When you have a problem with your application, how do you know where the error is? Hopefully, you are logging some useful information. In the case of really bad errors, you are logging a stack trace. Maybe you’ve seen that bizarre arrangement of methods, files, and line numbers. How the heck do you make sense of that thing? Why is it such a useful thing for debugging applications? Let’s learn how to read a stack trace.
So you’re moving your application to a web service API oriented architecture based on microservices. You’ve defined your endpoints to correspond to your application domain objects. You’re updating your applications to call these endpoints instead of making DB queries directly. Data access is now deployed in one place, instead of being spread across several applications.
Awesome.
But then you look up one day and find that you have to make a dozen, or perhaps even more, API calls in order to get all the data required to render a webpage. Things are slowing down, and complexity is increasing. What’s going on here? Isn’t this proliferation of web services supposed to make things better?
When you want to know what is happening inside of your application, the first place most people turn are the log files. If there’s a problem, one of the first things an experienced developer will likely ask is, “Are there any errors in the log files?” Effective application logging can be the key to solving application problems quickly and easily. When used poorly, they can be nothing but a bunch of noise, ignored by all, serving only to take up disk space.
“What should I do if the web service/database/etc. is down?”
Have you ever heard a variation of this question? Perhaps you’ve even asked it? This isn’t a terrible question to ask. It shows that you are considering the possibility that a problem could occur.
Do you know what your single responsibility as a software developer is? Consider this exchange from the movie City Slickers:
Curly: Do you know what the secret of life is? [points index finger skyward] This. Mitch: Your finger? Curly: One thing. Just one thing. You stick to that and the rest don’t mean [expletive]. Mitch: That’s great, but what is the “one thing?” Curly: That’s what you have to find out.
This scene has resonated with many as a great philosophy for approaching life. However, it can also be interpreted as a philosophy for software development.