Back to the homepage

Interview with Kamil Myśliwiec part 1

NestJS is a framework that fans have already had the opportunity to discover. If you haven’t yet though, check out our last article

We also closely follow the activity of the Nest creator – Kamil Myśliwiec. We find his journey so inspiring for us that we decided to contact him to conduct the interview. Especially for you, Kamil answered 25 questions! 

We invite you to the first part of the interview, in which we ask him about the history and future of Nest, also touching upon Angular.


Maciej Sikorski: What motivated you to create NestJS? Haven’t people advised you against writing your own framework?


Kamil Myśliwiec: When I started working on Nest in late 2016, I didn’t set myself any specific goals. I never even assumed that the project would eventually gain such popularity and turn into a full-fledged framework. You could say that at the beginning, it was just a side-project that I worked on late at night. I didn’t have any expectations though, I just continued to work on implementing new functionalities that I would like the framework I use to offer in the way that I thought was “the best”. Every Twitter mention or a Github star was very rewarding, a reason for joy and motivation for further work.


Was NestJS your first attempt to write your own framework? If not, what made you successful this time?


Like probably every software developer, I have repeatedly created my own ready-to-use “boilerplates”, micro-frameworks, which I then used in subsequent projects. However, Nest was the first framework of such scale that I decided to create. It’s worth mentioning, however, that the initial versions/sketches of the project differed significantly from the final version. There were ups and downs.


You’re saying that the sketches were significantly different from the final version. Does that mean that it wasn’t based on Angular at all at first?


From the very beginning, the architecture and many of Nest’s principles were inspired by the solutions used in Angular, but, indeed, the first prototypes did not have features such as guards or interceptors. What’s more, some decorators had slightly different names (for example, the @Injectable decorator did not exist), there were subtle references to Spring, which were wiped out quite quickly  ? There was also no CLI, which by the way relies quite heavily on @angular-devkit packages.


 What is your Angular experience?


My first experience with Angular, or rather its “ancestor” Angular.js version, dates back, if I remember correctly, to 2013. However, I must honestly admit that I’ve never been an enthusiast of this technology. In the following years, before the first versions of the Angular 2 “Developer Preview” came out, I was much more likely to reach for and work with React. 

The first project I worked on using the new Angular used its beta version (which, given the many “breaking changes” that had been released by the time of the final version, probably wasn’t the wisest choice). From that moment on, I was actively monitoring the state of the project and when a stable and usable version was published at last, I started using Angular regularly in my projects (although, as an interesting fact, I joined the first commercial project based on the “final” version of Angular as a React developer).


 What made NestJS so heavily based on Angular?


Over the years, I have often changed languages or toolsI’ve worked with (frequently as a result of switching jobs or projects). While I think it’s good to learn, to dive into several different technologies to get experience, to understand some language-specific techniques and to look at programming from different perspectives, I’ve also noticed how many things are conceptually similar, although named or designed in a completely different way. 

Unfortunately, in this case, it usually does not bring much value(in terms of our knowledge), and quite frequently,  it makes us  spend time learning how to achieve “the same” result in a different technology. We don’t learn techniques, concepts, but instead we try to remember the tool’s API, spending hours analyzing documentation. 

Nest framework serves as an example of what is possible despite two different worlds (backend and frontend), using similar nomenclature, comparable ideas, or very analogous solutions (in this case similar to Angular, whose nomenclature is very generic). it does not require reinventing the wheel. By using similar terminology and techniques, Nest is also much easier to grasp for people who already have experience in Angular and forms a sort of bridge to the backend world for people interested in backend development. Moreover, when working on two applications at the same time (FE and BE), the simultaneous use of Nest and Angular significantly reduces the cognitive overhead, so that “jumping” from one application to another and switching context does not require that much effort.


What were the biggest challenges/difficulties you encountered when developing NestJS?


There were many challenges, and it would be difficult  to choose the most impactful ones, although I think the main struggle I faced was changing my mindset. Building a typical end-user application is very different from designing libraries, especially on this scale. The goal was to create a tool that makes working with it as efficient as humanly possible, increases productivity, imposes some structure, while not limiting the developer, so that the framework never becomes a burdensome limitation. It is important to make difficult things a bit simpler, sometimes less time-consuming (and sometimes quite the opposite), and at the same time not to hold  users down by the tool itself. Against all odds, figuring out  the middle ground between flexibility and setting certain rules/boundaries & abstraction is a very challenging task, and the wrong choice is the most common reason for the failure of numerous tools.


Were there moments when you wanted to abandon this project?


Undoubtedly, the beginning was the hardest, as I worked on Nest mainly in the evenings, nights, and weekends, while during the day I was busy with  other duties, including a full-time job. There were months when my activity (in repositories) dropped almost to zero due to the overload of responsibilities. However, there has never been a critical situation in which I would consider abandoning the framework altogether.


What does the promotion of your own framework look like? What have you been doing, besides code development, that made NestJS so popular? Even a Discord server dedicated to NestJS always has more active users than the Angular-dedicated server.


When it comes to OSS projects “the word spread fast”, and on it’s own! I focused largely on writing code, maintained a Twitter profile for marketing purposes and occasionally published articles. Lectures at conferences and organised workshops also had a positive impact on increasing people’s awareness.


At what point did you consider Nest mature enough to present it at conferences?


If it was up just to me, I probably never would have made this decision (laughs). In late  2018, I was contacted by Zack, the organiser of the ngAtlanta conference in Atlanta. He said, “I’m organising a conference in four months and I’d like you to show up.” At the time, I didn’t  have a visa or even a valid passport. And that’s where it all started.


To what extent has creating the framework developed you as a programmer and manager?


For me personally, it is an extraordinary, priceless “baggage of experience”. I think the biggest stimulus for self-development is to be in touch with the developer community from all over the world. Publishing this type of project makes you, in a sense, exposed to possible criticism from all sides. You come across many ideas and concepts, not always in line with your original assumptions. This requires from you both the ability to argue certain decisions/assumptions (if they are right), but also reflection, self-criticism, the ability to discuss and, finally to improve yourself based on other people’s experiences.


Is there any interesting story related to the cat becoming the mascot of your project?


None! In fact, the only reason why cats are all over our marketing materials is because of my, sometimes excessive, love of them. Cats are mostly independent creatures, individualists, very proud animals, and this also, in a way, fits perfectly with Nest’s vision.


 What are the future plans for NestJS?


In the short term, first of all, the release of the v8 version, which has been awaited for several months. The new “major release” includes both small minor improvements (including automatic type inference even when using “dot notation” for the “config” package, the ability to buffer logs, or subscribing to the same event in parallel from several different controllers) and new functionalities, including the facilitation of application versioning and the ability to  lazy-load modules “at runtime” (although this mechanism is significantly different from what you can see in Angular). There will also be small documentation improvements, icluding a new chapter diving into serverless (this was one of the most popular issues in the repository). In the long run, of course, further development of the framework and the whole ecosystem that surrounds it.

The question was answered on June 23rd, 2021. NestJS 8 is already available – you can read more about it here.


Is there anything you want NestJS to “accomplish”? Do you have any next milestones or target point/a dream in front of your eyes?


I don’t have any specific and far-reaching expectations, but half-jokingly, I’ve always laughed that the main target would be to match Nest’s download statistics (NPM) with Angular ?



How can the NestJS community help develop their favourite framework and maintain its roadmap?


Mostly through direct help, i.e. solving issues reported by the framework’s community in the form of Pull Requests. Some of them are not very time-consuming and don’t require mastering/understanding the source code & internals, but rather just a few of its parts. Similarly, when there is a request to slightly improve a specific functionality – it’s worth considering whether, after creating an issue, you can propose a solution on your own, especially if it requires only a few lines of code to be modified.


Does the fact that the NestJS creator is Polish somehow affect the support for Polish NestJS developers? Can they count on some exclusive content (not considering this interview ?)? Some people postulate for the Polish version of the documentation, like in the case of the Vue.js one.

I have thought about creating a Polish version of the documentation many times in the past, and I would very much like it to be possible one day. The main barrier that, at the moment, makes it impossible to maintain multiple language versions is the time needed not only to translate all the chapters written so far, but also (or maybe above all) to maintain and keep updating the documentation down the road (when there are new features/examples). Generally,  documenting large projects is one of the most time-consuming elements of developing & maintaining a framework, and therefore, Nest only offers an English version for the time being. There have  also been several proposals to write a Polish book, and I gotta say that it would be a very entertaining challenge, but also in this case, I suppose  very engaging and requiring sacrifices & dedication. And obviously, I’m always happy to attend my favourite Polish conferences, NgPoland & JsPoland (greetings to Darek!),  and you can meet me there too. 


About the author

Maciej Sikorski

Maciej spends most of his time designing applications in Angular and Node.js, additionally he creates and supports libraries and other tools which he uses in his everyday work. He is heavily involved in the development of the NestJS technology and its community. He also runs a blog in English about NestJS and Angular.

Do you want to write articles for our blog together with us?
Join us and create valuable content for Angular fans with!

Leave a Reply

Your email address will not be published. Required fields are marked *