feat(post): lb4 testimonial @achrinza

blog/2022/2022-04-06-my-loopback-journey-from-exploring-to-contributing.md

@@ -0,0 +1,47 @@
+---
+title: "My LoopBack Journey: From Exploring to Contributing"
+date: 2022-04-01
+slug: my-loopback-journey-from-exploring-to-contributing
+authors: achrinza
+tags: [Testimonial]
+---
+
+Hi there! I'm Rifa, a member of the LoopBack Technical Steering Committee and an active maintainer of the LoopBack 4 project. In this article, I'd like to share my story and journey with LoopBack 4 within my organisation, the unique qualities that I saw in the project, and how I eventually got involved as an active contributor.
+
+<!--truncate-->
+
+## Discovering LoopBack 4
+
+I initially got an interest in the project back in 2019 when I was first researching for a Node.js framework to build my web applications on. Before stumbling upon LoopBack, I had tested frameworks and libraries of differing calibre such as Express, Nest.js, Hapi, and Sails.js; All of them claim to provide rapid developer on-boarding experience by providing abstracted, high-level APIs for developers so as to not require concern on the underyling implementation. All of this sounded great in theory; However, we quickly found that many of these promises of accelerating developer cadence broke down the moment that we needed to implement custom functionality which the frameworks did not account for.
+
+As basic HTTP and REST frameworks and libraries, they are well-suited for quickly buiding applications as developers need not worry about the nooks and crannies of developing web APIs. However, upholding this abstraction is simply not possible with every project, and eventually we would need to work at the protocol-level to cater to our business requirements or use a coding paradigm that was outside of the expectations of the framework developers. This meant digging through the underlying framework code to understand its inner-workings or outright working around the system, effectively removing the nice abstractions that were built.
+
+> "Frameworks typically take an all-or-nothing approach - Either follow our application architecture style, or don't use it at all."
+
+This proved to be detremental to our projects, and meant that there was a level of unpredictability in the software development lifecycle in projects that implemented these frameworks; We were unable to fully account for the limitations of the frameworks, and were bogged down by the need to implement our own variation of certain fundamental abstractions that simpler libraries (such as Express) did not offer. This led to development time being unecessarily spent architecting and implementing solutions that did not solve the immediate business requirements which in turn led to code which required more maintenance, was not easily understood by different teams, and had incompatible approaches to solving similar issues. This led to code debt and time spent continuously reviewing and updating each project to synchronise them with new coding practices and paradigms that we may adopt. This compromise between ease of use and the need to architect each project ourselves proved challenging, and did not bode well for the longevity and maintainability of each project, putting them at an uneeded risk for a rewrite as the fast-paced Node.js ecosystem continues to develop new approaches to solving the same issues.
+
+## 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.
+
+> "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 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
+
+With all of these features of the framework, I felt that it was only right for me to contribute back to the project. To preface, I do not believe that the first contributions to any open source project needs to be a bombastic, technical pull request to implement a feature or fix a bug. In fact, my first pull request was merely removing a leftover pre-GA (General Availability) message in the GDPR docs! It wasn't until a few months later, after extensively reading the documentation and reading the codebase, did I create my first pull request which modified the source code. Over time, I slowly built the confidence to create more in-depth pull requests and got them merged, but creating bigger PRs was never the end goal: I knew I did not have the full knowledge of the codebase, and instead chose to focus on the smaller things that the existing maintainers may not have had the time to focus on. Over time, my contributions were noticed and I was reached out by one of the maintainers to join the team as a community maintainer; This accelerated my drive and commitment to support the project as I was now empowered to merge PRs and support the rest of the community through Slack and their own issues and PRs as well.
+
+But even without a maintainer status, rest assured that your contributions are and will be valued! I didn't contribute with the intention of becoming a maintainer (nor was I expecting it!). Instead, I contributed because I saw the potential in the open source project and its unique propositions in the Node.js ecosystem. Although sometimes we may be slow to respond, we really do value every opened issue and PR that the community opens, and we hope that we can continue to support the community where we can!
+
+With the shift of ownership from IBM to the OpenJS Foundation, I am even more confident in the future of LoopBack 4 as being an independently-managed open source project. This change signals the importance of LoopBack 4 as a strategic project, and ensures that it does not get tied down to the needs of a single organisation. This means no "Open Core" model, or upselling of a propreitary product through LoopBack 4, or blocking of features due to conflicts with an organisation's existing strategic product or service.
+
+As such, I would like to end this with a warm thanks to the LoopBack 4 maintainers team that took the risk and brought the vision of LoopBack 4 into reality; I would not be in this position it weren't for their hard work and forward planning of the team.

blog/authors.yml

@@ -68,4 +68,10 @@ b-admike:
   name: Biniam Admikew
   title: LoopBack Maintainer
   url: https://github.com/b-admike
-  image_url: https://avatars.githubusercontent.com/u/13950637
+  image_url: https://avatars.githubusercontent.com/u/13950637
+
+achrinza:
+  name: Rifa achrinza
+  title: LoopBack Maintainer
+  url: https://github.com/achrinza
+  image_url: https://avatars3.githubusercontent.com/u/25147899