fix: apply @dhmlau's patches

achrinza · achrinza · commit 23343cea0214 · 2022-04-05T17:40:41.000+08:00
Signed-off-by: Rifa Achrinza &lt;25147899+achrinza@users.noreply.github.com&gt;
diff --git a/blog/2022/2022-04-06-my-loopback-journey-from-exploring-to-contributing.md b/blog/2022/2022-04-06-my-loopback-journey-from-exploring-to-contributing.md
@@ -1,7 +1,7 @@
 ---
-title: LoopBack 4 Maintainer's Testimonial - Rifa Achrinza
+title: "My LoopBack Journey: From Exploring to Contributing"
 date: 2022-04-01
-slug: maintainers-testimonial-rifa-achrinza
+slug: my-loopback-journey-from-exploring-to-contributing
 authors: achrinza
 tags: [Testimonial]
 ---
@@ -22,17 +22,18 @@ This proved to be detremental to our projects, and meant that there was a level
 
 ## The "LoopBack Advantage"
 
-Hence when we discovered LoopBack 4, we were drawn and equally taken aback by the unorthodox approach it took when we discovered it; Like many others, we initially questioned the need for the significant amount of APIs, configuration files, and Node.js packages. As a project that angles itself as purely a REST framework, why was it visibly more complex? As we dug into how each package functions and the unique properties of the "LoopBack Approach", we realised we found a framework that had potential in solving the pain points of other projects. As we started building projects with LoopBack 4, we were initially frustrated and confused for the need of dependency injection and decorators; As the most of the Node.js ecosystem did not implement these features, we did not fully-understand the need for them and saw them as needless complexity. It was only as we continued to build our projects did we soon realise the true strength of LoopBack 4.
+Hence when we discovered LoopBack 4, we were drawn and equally taken aback by the unorthodox approach it took when we discovered it; Like many others, we initially questioned the need for the significant amount of APIs, configuration files, and Node.js packages. As a project that angles itself as purely a REST framework, why was it visibly more complex? As we dug into how each package functions and the unique properties of the "LoopBack Approach", we realised we found a framework that had potential in solving the pain points of other projects. As we started building projects with LoopBack 4, we were initially frustrated and confused for the need of dependency injection and decorators; As the most of the Node.js ecosystem did not implement these features, we did not fully understand the need for them and saw them as needless complexity. It was only as we continued to build our projects did we soon realise the true strength of LoopBack 4.
 
 > "There was an overwhelming amount of APIs, and in turn a steep learning curve. However, it paid off in the end."
 
 What we eventually found was a framework which had already solved all of our architectural problems from the get-go. The dependency injection framework provided us with a common, easy-to-understand system to store and share configuration and class instances with the rest of our project without concern on which "subsystem" depended on it. This allowed us to bind once, and have all the dependents grab it as needed. Moreover, LoopBack 4 goes a step further and provides powerful APIs surrounding dependency injection, including listeners, nested contexts, factory functions, and provider classes. Combined together, they allowed us to abstract implementation details of each interdependency (Such as if they are dynamically generated through factory functions or providers), and allowed the dependents to make assumptions without the same hard restrictions that would've been imposed otherwise. This meant that we were able to build more rapidly and consistenly without needing to wonder how it was done before.
 
-In addition, the stacked approach towards the framework's different Node.js packages meant that we could gracefully move to the next lower layer of abstraction of APIs if needed. However, this proved to be less necessary with LoopBack 4 due to its approach of exposing as much APIs as possible to the developer. This meant that we had unprecedented access to many of its inner-workings, and are able to interact with them without without concern if its considered unsupported. This flexibility also extends to the use of third-party Node.js packages; Because a LoopBack 4 project is also a Node.js app at its core, we're able to add and replace packages as needed; This meant that we were able to swap the default Juggler ORM (Object-Relational Mapping) with our own, or even decide to outright not use an ORM when the project did not interact with a database.
+In addition, the stacked approach towards the framework's different Node.js packages meant that we could gracefully move to the next lower layer of abstraction of APIs if needed. However, this proved to be less necessary with LoopBack 4 due to its approach of exposing as much APIs as possible to the developer. This meant that we had unprecedented access to many of its inner-workings, and are able to interact with them without concern if its considered unsupported. This flexibility also extends to the use of third-party Node.js packages; Because a LoopBack 4 project is also a Node.js app at its core, we're able to add and replace packages as needed; This meant that we were able to swap the default Juggler ORM (Object-Relational Mapping) with our own, or even decide to outright not use an ORM when the project did not interact with a database.
 
 This transitions well into the next great thing about LoopBack 4 - Its flexibility lends itself to being a great candidate for projects that are not related to web APIs. In `@loopback/core`, abstract concepts such as Lifecycle Observers, Servers, and Services provide the foundational building blocks for virtually any enterprise Node.js project. Hence, when we needed to build a CLI, we were able to re-use many of the non-HTTP LoopBack 4 packages, thereby exploiting many of the same abstractions that we came to love with LoopBack 4. Although we had to implement our own "CLI Server", we were able to build one with confidence as we were already familiar with the "LoopBack Way", and were able to progressively build these internal framework extensions with the same principles of exposing as much of the API to the developer, and providing a graceful approach to "step down" from the abstraction. We've been continuing to enhance this CLI framework internally, and were able to progressively iterate it over time to suit our needs, and we hope to be able to contribute it back to the LoopBack 4 open source project in the future once we're confident in its maturity.
 
 Finally, the major advantage of LoopBack 4 is that it does not hide its configuration files; As alluded to earlier, a starter LoopBack 4 project would contain swaths of configuration files for the TypeScript compiler, Prettier, ESlint, etc. Although this may look intimidating at first, this approach may actually be beneficial to many developers. Due to LoopBack 4's assumption that the developer may tweak these configuration files themselves, there isn't an "ejected" state like many other frameworks. This means that we are able to still utilise the LoopBack 4 CLI, even as we tweak a configuraiton here and there. As such, we were able to learn the ins and outs of a typical LoopBack 4 project while still having the support of the CLI to accelerate our workflow.
+
 All of what I have mentioned above are just some of the features that I admire in LoopBack 4, and there are many more intricate and hidden gems in the framework that I did not get to talk about. But generally, if you need a reason to LoopBack 4, it should be these: It's extremely extensible, it is not opinionated in the typical sense, and it is a "meta framework" (i.e. You can build any Node.js app with it!).
 
 ## Contributing Back
