4 ms·

More and more software, especially on the web, is asynchronous microservices. Debuggers are basically useless for both of those imo. Debugger break points int

More and more software, especially on the web, is asynchronous microservices. Debuggers are basically useless for both of those imo. Debugger break points introduce synchronous behavior into your async application, which basically forces race conditions to fail when debugging. And I'll admit to not being a debugger expert but I don't know of any that can watch multiple executibles at once.

sanderjd 3y ago
IMO, this is one of the reasons that architectural style is not actually very good...
randomdata 3y ago
There shouldn't be a need to connect to another service during debugging except maybe to validate that an external service stands by its published contract. A debugger (nor printf) does not seem like the right tool for that job, though.
- bluefirebrand 3y ago
  If you're not sure which service is causing the error, combing a log output from the two services is much easier than debugging each service separately, is my point.
  - randomdata 3y ago
    1. How does this really differ from debugging both services at the same time and attaching logpoints? 2. Microservices is a team separation technique, allowing different team to live in isolation, sharing only API documentation. It's the same as regular web services, except within a single organization instead of across organizations. If you happen to have access to the code (not a guarantee!), are you really going to be able to jump into a codebase you're not familiar with to start adding print lines with more expediency than other possible approaches?
    - rolisz 3y ago
      Re 2: tell that to the company I used to work with. Management heard microservices are good? Then we should have nano services. They mandated that we split things up super small, by functionality, even if there was only one team working on that.
    - edgyquant 3y ago
      Microservices are more than just an organizational abstraction. They allow you to scale up services as needed for one thing.
      - randomdata 3y ago
        Yes, that's right. Teams not needing to communicate, beyond API contracts, allows them to scale the service they provide. When sharing code in a monolith then you have to meetings when you want to make changes that impact other developers, and that will soon take your whole day when there are thousands of workers, leaving no time to do anything. That leaves service that cannot scale. More simply, it takes how the macro economy scales software (and, really, most everything) and tries to apply the same processes in the micro.
        sanderjd 3y ago
        A service layer is not necessary to have an API contract.
        randomdata 3y ago
        But you do need people providing service in order to emulate macro services in the micro.
        sanderjd 3y ago
        I honestly can't make heads or tails of this. Can you expand on what you mean?
KRAKRISMOTT 3y ago
Or God forbid those Next.js apps where the same line of code is ran on the server, streamed to the client, and then ran again on the client via rehydration. 3 different potential sources of failure and you have to debug them simultaneously.
fulafel 3y ago
There are various kinds of debugger. For investigating systems like this I think you want a trace / time travel based debugger, like eg FlowStorm in the Clojure world.
flohofwoe 3y ago
This just means that debuggers have to catch up. Anything that runs on a CPU is also debuggable, and if it's too much hassle, the debuggers need to improve. Debuggers are much more than just stepping through code and setting breakpoints, they are (or should be) "interactive program state explorers and visualizers". (IMHO no programming language should add features which make interactive debugging harder, it's never worth it in the long run)
The_Colonel 3y ago
I don't understand the problem, why can't you simply run the debugger of your choice multiple times, each for one process?
- bluefirebrand 3y ago
  Sure. But I also might not be running one of the services in my personal dev environment.

sanderjd 3y ago

IMO, this is one of the reasons that architectural style is not actually very good...

randomdata 3y ago

There shouldn't be a need to connect to another service during debugging except maybe to validate that an external service stands by its published contract. A debugger (nor printf) does not seem like the right tool for that job, though.

bluefirebrand 3y ago
If you're not sure which service is causing the error, combing a log output from the two services is much easier than debugging each service separately, is my point.
- randomdata 3y ago
  1. How does this really differ from debugging both services at the same time and attaching logpoints? 2. Microservices is a team separation technique, allowing different team to live in isolation, sharing only API documentation. It's the same as regular web services, except within a single organization instead of across organizations. If you happen to have access to the code (not a guarantee!), are you really going to be able to jump into a codebase you're not familiar with to start adding print lines with more expediency than other possible approaches?
  - rolisz 3y ago
    Re 2: tell that to the company I used to work with. Management heard microservices are good? Then we should have nano services. They mandated that we split things up super small, by functionality, even if there was only one team working on that.
  - edgyquant 3y ago
    Microservices are more than just an organizational abstraction. They allow you to scale up services as needed for one thing.
    - randomdata 3y ago
      Yes, that's right. Teams not needing to communicate, beyond API contracts, allows them to scale the service they provide. When sharing code in a monolith then you have to meetings when you want to make changes that impact other developers, and that will soon take your whole day when there are thousands of workers, leaving no time to do anything. That leaves service that cannot scale. More simply, it takes how the macro economy scales software (and, really, most everything) and tries to apply the same processes in the micro.
      - sanderjd 3y ago
        A service layer is not necessary to have an API contract.
        randomdata 3y ago
        But you do need people providing service in order to emulate macro services in the micro.
        sanderjd 3y ago
        I honestly can't make heads or tails of this. Can you expand on what you mean?

KRAKRISMOTT 3y ago

Or God forbid those Next.js apps where the same line of code is ran on the server, streamed to the client, and then ran again on the client via rehydration. 3 different potential sources of failure and you have to debug them simultaneously.

fulafel 3y ago

There are various kinds of debugger. For investigating systems like this I think you want a trace / time travel based debugger, like eg FlowStorm in the Clojure world.

flohofwoe 3y ago

This just means that debuggers have to catch up. Anything that runs on a CPU is also debuggable, and if it's too much hassle, the debuggers need to improve. Debuggers are much more than just stepping through code and setting breakpoints, they are (or should be) "interactive program state explorers and visualizers". (IMHO no programming language should add features which make interactive debugging harder, it's never worth it in the long run)

The_Colonel 3y ago

I don't understand the problem, why can't you simply run the debugger of your choice multiple times, each for one process?

bluefirebrand 3y ago
Sure. But I also might not be running one of the services in my personal dev environment.