Categories
Backend Frontend

3 JavaScript Libraries that changed the way I develop Full-Stack Projects

In the dynamically-evolving (or, if you insist, absurdly inflated) JavaScript library ecosystem, every once in a while I come across a new module, which considerably impacts the way I build my projects as a full-stack developer. I’ve decided to compile a short list of three JavaScript libraries which I have discovered over the last two years that greatly improved my workflow and have become my go-to choice when developing full-stack applications.

Just to give you some perspective into what I usually do, most of the projects that I develop consist of a backend application exposing a RESTful JSON API, that is consumed by a frontend app written in React.js, sometimes developed in conjunction with Gatsby.js or Next.js depending on the project’s requirements.

NestJS – a progressive Node.js backend application framework

For developing small to medium size applications, Node.js is my preferred server-side environment largely due to its flexibility resulting in significant reduction in project delivery times. Prior to discovering NestJS, I’ve tried numerous Node.js backend applications in the past including Express, Fastify, Hapi and FeathersJS.

One of the key reasons why I prefer NestJS over its alternatives is that code written following its convention is, to a great extent, declarative rather than imperative. NestJS makes extensive use of TypeScript decorators, and neatly integrates with TypeScript itself (i.e. when performing request validation using class-validator annotations and validator pipes).

While I still use Express and Fastify for smaller projects, NestJS is my go-to choice when it comes to developing CRUD-intensive backend applications as well as projects, in which I anticipate a considerable increase in the number of functional requirements over the project’s lifetime. While NestJS’ rather strict convention introduces a significant amount of boilerplate code, it reduces ambiguity and allows for writing declarative code, which is especially beneficial when larger teams are working on the same codebase.

SWR – declarative data fetching for React.js

If you have ever written a React.js application which fetches data from API endpoints in numerous places across the entire application, you probably know how much boilerplate code it usually involves. While you may be tempted to extract such logic into a separate data fetching hook, it is rather painful to develop additional functionalities such as interval-based refreshes, error retries and optimistic UI updates by hand. SWR offers all of the aforementioned functionalities and much more, while using concise and declarative syntax.

In most of my projects, using SWR allowed me to ditch the Redux state store in favour of SWR + React Context API combo. Consequently, all of the regular data fetched from the backend application endpoints resides in SWR’s cache, while things that are unlikely to change such as the user’s account data, JWT or session token are placed in rather succinct global state accessed via React Context Provider.

react-hook-form – elegant form handling without unnecessary boilerplate

In the past, I have used controlled components and Formik for handling forms in React.js. While the former tend not to scale well, the latter introduces a significant amount of boilerplate. I was surprised how much functionality can be squeezed out of react-hook-form while using minimal amounts of fairly declarative code. One functionality, which I tend to use the most is the reset() method, which comes in very handy when pre-filling forms with remotely fetched data.

Leave a Reply

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