text: We call these solutions*traditional*because request/response has been the model for web 
  
  applications for decades. We call them*monolithic*because everything is provided in one package. 
  
  Traditional frameworks do an awful lot, but can be awfully complex doing it. 
  
  To be fair, traditional development does have advantages. Developer workstation setup is generally 
  
  quick. You typically setup a package manager or installer such as NPM, Gradle, Maven, homebrew, 
  
  or a custom CLI to initialize a new application, then you run the bare bones app with a command. 
  
  Frameworks that bring everything can boost initial productivity, especially when starting with a 
  
  simple solution. 
  
  But, this everything in one box approach makes scaling and troubleshooting problems diﬃcult. As 
  
  an application grows, it tends to rely on more external systems. Asynchronous integrations with 
  
  these systems are preferred because they do not block the ﬂow. But, asynchronous requests are 
  
  diﬃcult to invoke and troubleshoot in a traditional architecture. 
  
  For asynchronous actions, the application logic must include timeouts, retry logic, and the status. 
  
  Single errors can cascade and impact many components. Work ﬂows become more involved just to 
  
  <html>
          <head> <meta charset="UTF-8">
          <style>
          table, th, td {
              border: 1px solid black;
              font-size: 10px;
          }
          </style> </head>
          <body>
          <table frame="hsides" rules="groups" width="100%%">
              [html]<thead><tr><td>Increases ( or decreases ) in demand for a particular feature require scaling up ( or down ) the entire</td><td>system. This is inefficient and difficult because all of the components and state are tightly coupled</td></tr></thead><tbody><tr><td>together.</td></tr><tr></tr></tbody>
          </table> </body> </html>
  
  Traditional development  18 