DEV Community: Anton Bahurinsky

5 tips for better Swagger docs in NestJS

Anton Bahurinsky — Thu, 04 Jul 2024 13:05:25 +0000

Swagger is a powerful tool for documenting RESTful APIs when working with NestJS. And the NestJS developers have done great job for our comfortable work with Swagger within the framework. Now it is our responsibility as developers to apply this tool at its full potential and thus to make another bit of contribution of making this world a better place.

1. Document all endpoint response codes

When you develop a RESTful API (for example, on NestJS), there usually is a consumer of it: a frontend. The frontend is often developed by other people (than you/backend) who may not have access to the backend and/or enough backend skills. Thus, an API description is the simplest way to know what they are working with (against).

Frontend developers often have to handle different cases like invalid input, failed authentication, taken email address etc. And response codes are the way for them to know what actually happened on the backend.

Take some time to add decorators like @ApiCreatedResponse(), @ApiBadRequestResponse() or @ApiConflictResponse() to your endpoints. Some of them (like @ApiInternalServerErrorResponse()) don't even have to be added to every endpoint, but simply to a controller.

Additional descriptions may also me helpful:



// auth.controller.ts
@ApiConflictResponse({
  description: 'When the username is already taken.',
})
@Post('signup')
async signup() {
  // ...
}

2. Describe request and response return types

Just like with response codes, API consumers have to know what an endpoint consumes and returns. It is relatively easy to have those types in sync with actual code (see how SignupDto and LoggedInDto are used here):



// auth.controller.ts
@ApiBody({
  type: SignupDto,
})
@ApiCreatedResponse({ type: LoggedInDto })
@Post('signup')
async signup(@Body() signupDto: SignupDto): Promise<LoggedInDto> {
  // ...
}

3. Provide examples of field values

Remember, Swagger is not only declarative, it is interactive. This means that users are not only able to read the API docs, but also to make requests.

Defining field value examples will not only tell API consumers about what to expect. If a field value example is defined for an input entity or DTO, it becomes a default value for making requests:



// login.dto.ts
export class LoginDto {
  @ApiProperty({
    example: 'alice',
  })
  @Allow()
  username: string;

  @ApiProperty({
    example: 'Alice1111$',
  })
  @Allow()
  password: string;
}

4. Enable user authentication

When applicable, of course.

One of the most popular authentication mechanisms for RESTful APIs are bearer access tokens. These tokens are often JWT, but their format doesn't affect our example.

In order to enable bearer token authentication you will first need to enable it in your main.ts, where you are defining and applying Swagger:



// main.ts -> bootstrap()
const config = new DocumentBuilder()
  // ...
  .addBearerAuth({
    type: 'http',
    scheme: 'bearer',
    in: 'header',
  })
  // ...
  .build();

And then apply the @ApiBearerAuth() for an auth-restricted endpoint (or for entire controller if all its endpoints are restricted):



// auth.controller.ts
@Get('me')
@ApiBearerAuth()
async me() {
  // ...
}

5. Manage tags

While being optional, tags are a great way of ordering the API endpoint groups. With tags, you can place the most used endpoints of the API to the top, which will increase the Swagger API efficiency for the entire team. In our example, database seeding and authentication endpoints are the most frequently used. Here is how we place them at the top:



// auth.controller.ts
@ApiTags('auth')
@Controller('auth')
export class AuthController {
  // ...
}



// main.ts -> bootstrap()
const config = new DocumentBuilder()
  // ...
  .addTag('seed')
  .addTag('auth')
  // ... rest of tags
  .build();

Conclusion

That's it for now! Hope these tips will make you a good service.

If you want to see how everything from this post is implemented within an actual NestJS application, check out this repository.

If you have more ideas of how to improve Swagger API documenting, don't hesitate to leave a comment!

Don't stop coding, don't stop growing, and choose the good side 🇺🇦

NestJS: stop handling errors like this!

Anton Bahurinsky — Wed, 30 Mar 2022 15:20:42 +0000

I see people making this mistake all the time.

Let's say you've got an API server written in NestJS, and you need an endpoint for fetching a single product by its ID. So, in your product.service.ts you would typically write:

async findOne(id: number) {
  try {
    return await this.productRepository.findOneOrFail(id);
  } catch (err) {
    throw new NotFoundException();
  }
}

(I'm using TypeORM here, but the same principle can be applied to other libraries as well.)

So what we've got here? You attempt to query a product by its ID, and if there is no product with this ID, you just throw the 404. And in your product.controller.ts you simply write:

@Get(':id')
findOne(@Param('id') id: string) {
  return this.productService.findOne(+id);
}

And everything indeed works fine.

So what's the problem with this?

The thing is that the above code would work well for REST APIs. But what if tomorrow you will need to fetch that product via GraphQL or WebSockets? The NotFoundException() and its fellow HTTP-related exceptions will not be suitable for that any more. You will definitely need different error handling.

Therefore, by throwing HTTP-related errors (exceptions) from services you simply make your code less reusable.

What to do instead?

As we have implicitly mentioned above, the HTTP-related exceptions are suited only for REST APIs. But so are controllers!

You see, NestJS controllers are used only during REST API development, while services can have wider use. This makes controllers the perfect place for throwing HTTP-related exceptions.

Thus, in the simplest scenario, your product.service.ts code (fragment) would look just like this:

findOne(id: number) {
  return this.productRepository.findOneOrFail(id);
}

And in the product.controller.ts you now handle the "not found" error:

@Get(':id')
async findOne(@Param('id') id: string) {
  try {
    return await this.productService.findOne(+id);
  } catch (err) {
    throw new NotFoundException();
  }
}

Of course, if you need more sophisticated error handling, you can define custom error classes to throw from services and handle in controllers (for REST) or resolvers (for GraphQL).

Conclusion

Don't throw HTTP-related exceptions from services, throw them from controllers!

Have you been making this mistake before reading this article? Comment down below!

And, of course, leave your reaction to this article, share it with your friends via social media and follow me on this platform!

Don't stop coding,
don't stop growing,
stand with Ukraine! 🇺🇦

Stop using polyrepo (until you read this)

Anton Bahurinsky — Tue, 22 Mar 2022 10:51:39 +0000

Stop using polyrepo (until you read this)

"Monorepo vs polyrepo" is one of important questions that arise when you start working on a new web project. In this article you will learn about basic rules of when to apply either monorepo or polyrepo approach to your web application and the benefits each of the approaches provides.

There are a lot of great frameworks and platforms for developing web applications, front-end and back-end. However, most (all?) of them provide tools for initialization and further work with an application as a standalone repository.

Initially, there's nothing wrong with that: it is the simplest way to get started. But as a consequence, during your web developer career you basically get educated to the polyrepo-first approach.

Later on, as a constantly learning developer, you start to explore what the monorepo is and its potential benefits. So when you start developing your next web application, you ask a fair question: "What are the reasons to use monorepo for this project?"

But the truth is that the power of monorepo approach can very much make us change the thinking direction itself! So upon starting a new web project we now ask: "What are the reasons NOT to use monorepo?"

Monorepo-first approach

Imagine you are starting the work on a new client-server web application (i.e. its architecture contains two nodes: a front-end client and a back-end server). If you choose the monorepo approach for this project, this will provide you a line of benefits.

1. Integrity of development process

Developing a feature usually involves changes in both client and server. With monorepo, all the feature code is wintin a single pull request, which makes development, testing and code review processes more stable.

2. Better deployment automation

Since a new feature code is under a single pull request, it allows you to automate the CI/CD flow for all (affected) nodes upon a single merge. Thus, you are able to re-deploy both client and server as a single operation, and this in turn allows to automate execution of end-to-end tests in correct moments.

3. Easier for pipelines

With some additional tools for managing monorepos you can trigger testing and re-deployment only for the nodes that contain changes and their dependents, aka affected nodes. For example, if you have changes only on the client, you don't have to re-deploy the server. This will reduce overall pipeline usage, which will eventually benefit your wallet and clock.

4. Easier code sharing

If all the nodes of your monorepo are written in the same language (e.g. TypeScript), it is very easy to share code between nodes. For example, you can import data types from server to client, so the client knows which data to expect upon network requests.

All this comes with relatively low cost: one more tool int your toolchain for monorepo management and some additional configuration of your frameworks to adapt them for monorepo.

As you can see, the benefits fo using monorepo outweigh its maintenance costs. And this is a sufficient reason to consider monorepo as a default approach.

When not to use monorepo

Of course, "default approach" doesn't mean "the only approach". Everything is a trade-off, and "monorepo vs polyrepo" is not an exception.

The highlighted benefits of monorepo are the most notable when your development team consists of full stack developers, i.e. when each feature (module) is being developed by a single responsible person.

On the other hand, if you have separate front-end and back-end developers for the client and the server respectively, then the benefits of monorepo diminish.

Another valid reason to consider polyrepo is when you have some kind of secret algorithm or flow on, for example, the server, so you want to restrict access to it only to trusted people. With polyrepo you can achieve that, still being able to involve freelancers for frontend-only tasks.

Conclusion

In this article we have discussed why you should take monorepo as default approach for web development. We have also named valid reasons when you should consider polyrepo for your project.

Of course, as an example we took an application consisting only of two nodes: client and server. But the ideas from this article can certainly be scaled up for more complex architectures.

What is your experience with monorepos and polyrepos? Don't agree with something? Share it in comments!

If you like the ideas from this article and find them useful, don't forget to leave your reaction and follow me on this platform!

Don't stop coding,
don't stop growing,
stand with Ukraine! 🇺🇦

Testing web apps: what you didn't know

Anton Bahurinsky — Wed, 23 Feb 2022 18:21:03 +0000

Quality assurance is an important part of web development. In correspondence, a significant part of the QA is testing.

The testing itself is a resource-consuming activity. So it is important to perform it correctly in order to achieve maximum benefit with minimal effort (the definition of efficiency).

Of course, you already heard about unit, integration and end-to-end (E2E) tests. And you have undoubtedly seen this testing pyramid:

The main idea represented by this pyramid is that the majority of test cases must be covered with tests of a lower level, you write a higher-level test only when the test case can not be covered with the lower-level ones.

What does this mean for us in practice? Since, due to the pyramid, unit tests are the most basic ones, they should be written in the first place, and only when we feel we are not able to cover a test case, we proceed with integration tests, right?

WRONG!

What is the problem with this approach?

The thing is that the primary criteria of correctness of work of a web application is its technical requirements. Such requirements are usually written by stakeholders of the application (or under their review).

So when you write E2E tests, you are actually covering test cases defined by the requirements. This means that you are 100% sure that your tests cover a necessary thing.

On the other hand, if you start covering the app from a unit test against, for example, a utility function which calculates the total cost of the cart, how do you even know you are ever going to need this function in your code?

I mean, most probably you will be right in assuming that you will eventually need it. But even if you will, you are guaranteed to fail in predicting the exact API of the function (e.g. number and type of arguments or return value format). And this alone may make all the unit tests against this function completely useless.

In turn, because E2E tests are the highest-level tests, they cover the backbone of a feature (e.g. the entire cart), while leaving you some flexibility for implementation details.

In other words, do whatever you want in the code, just don't break the E2E test.

So now, going back to the cart total cost utility function, I might not cover it with unit tests at all, because it is an implementation detail by itself (which barely worth my attention)! Even if I make a mistake in the function's logic, that's not a big deal, since it is easy to fix. I might even replace the function with a different one (with identical API, of course).

So you have already got my point: write E2E tests first.

Of course, although E2E tests are the most significant tests, they are also the most expensive to write and maintain. That's why it is important to cover with E2E tests only what can't be covered with lower-level tests to avoid over-testing. Otherwise, this will increase cost of the tests themselves and reduce flexibility of the code, which in turn will make further development harder.

So, we have determined the only correct direction of writing automated tests due to the testing pyramid: from top to bottom.

Manual tests

Nevertheless, there is a type of tests that is even on a higher level than E2E tests. Those are manual tests.

Everything tested by an E2E test can be tested by a determined manual test as well. In fact, an E2E test is a derivative of a corresponding manual test. The only reason you are writing E2E tests is that you don't want to perform manual testing on every update (i.e. you want to automate the testing process).

Thus, the testing pyramid might as well look like this:

With manual tests you can cover even more test cases than with E2E tests (in fact, you could cover those cases with E2E tests too, but that would make them unreasonably expensive).

Manual tests have the highest maintenance cost, but the lowest creation cost. You can simply write down test steps on a piece of paper - and you've got a manual test!

This makes manual tests especially useful for some cases like, for example, when you are not sure about your code structure yet, or when the technical requirements are incomplete or are likely to change, or when there is a time pressure and it may make sense to temporarily sacrifice automated testing.

Conclusion

Now, after reading this article you know the only correct way of web application testing: don't start from unit tests, start from E2E or manual tests. Do you agree with this approach? Or have you invented something better? Write in comments!

And of course leave your reaction to this article, share it with friends, and follow me on this platform for future articles!

Don't stop coding, don't stop growing!

SQL vs MongoDb: what nobody tells you

Anton Bahurinsky — Tue, 22 Feb 2022 18:07:21 +0000

So you are starting the work on a brand new web application. You're picking up tools for the development, and one of them is a database (or, better said, a database management system - DBMS). You already know all the differences between SQL-based systems and MongoDb (there is plenty of information about this, so I won't duplicate it in this article).

But despite of this knowledge, you are still in doubt what kind of DBMS to choose (and there's nothing strange to this: it is a damn important decision!). If you've ever experienced this feeling, like this article right now and share it with friends!

However, this is much simpler than it may seem to be, at least in theory. I'll give you a straightforward rule about choosing a DBMS:

if you application works with unstructured data, then choosing NoSQL would be a no-brainer (here I don't necessarily mean MongoDb, since depending on your needs, other type of NoSQL databases may fit your app better);
otherwise, if the data of your application has a predefined structure, then SQL would be a good choice.

That sounds easy, doesn't it?

Most of web applications work with structured data (arguably). But before executing that CREATE DATABASE ... command for your new web app, it may make sense to consider a couple of factors.

First of all, initial maintenance costs of SQL-based systems are higher than of MongoDb (yes, from here I'm focusing on MongoDb again).

What do I mean by that? The thing is that due to the fixed data structure of SQL databases you will have to deal with database migrations. This means adding an entire step to your CI/CD flow. And this step is not fool-proof at all: remember that your app will eventually work with production data.

On the other hand, however, SQL databases (if used correctly, of course) will definitely make your data more stable, e.g. they will eventually help to reduce the number of bugs.

This means that the SQL vs MongoDb stuff is a classic stability-flexibility tradeoff.

At this point I may suppose that you probably expected a more exact advice when you read the title of this article. Giving advices is easy, that's why I won't do that :)

Instead, I can tell you about my own approach of selecting a DBMS.

In most cases (if not always) I work with web apps of structured data, I have mentioned something like that above. However, I often choose MongoDb for such apps, and not only because of its greater flexibility. The thing is that remote MongoDb storage services are generally more affordable than SQL, which is especially beneficial for toy projects and startups.

But ultimately I don't like asking the question: "Which DBMS should I marry my app with?".

Instead, I ask: "What if I choose wrong DBMS now, and how can I fix this mistake in the future?" (remember that humans are bad in predicting the future?).

So, to mitigate this risk, there are a couple of good ORMs we can apply, for example, Prisma. If at some point you decide to switch from SQL to MongoDb or vice versa, Prisma will help you to reduce costs of such transition.

And this is basically it what I think about the SQL vs MongoDb problem. Did I miss something? Write in comments! And don't forget to follow me so you don't miss out future articles!

Don't stop coding, don't stop growing!

TypeScript vs vanilla JavaScript for your next project

Anton Bahurinsky — Tue, 22 Feb 2022 08:45:36 +0000

While choosing between TypeScript and vanilla JavaScript for a web application it is important to understand that all web applications work with data.

In case when your the data structure of your application is not fixed, then TypeScript would be an overkill for such application.

But most of web applications work with data that has a strictly defined structure (of course the structure evolves during the app lifetime, but this still doesn't change the game rules).

In such case applying TypeScript to you app will significantly improve the quality of your code. And that comes with almost no additional maintenance cost, since most of modern development tools offer great integration with TypeScript.

What is your opinion about this? If you agree with me, leave your reaction to this post! If not, comment your objections down below!

And remember: don't stop coding, don't stop growing!

Why choosing right development tools is so important

Anton Bahurinsky — Mon, 21 Feb 2022 10:13:52 +0000

TL;DR: This is a story from my own professional experience about how picking wrong libraries, frameworks, infrastructure services and development approaches causes damages to a web application, thus doubling time and cost of its development.

It was a brand new e-commerce project with a fresh business idea, which involved development of a web application. The stakeholders were two ladies, and one of them has known a guy called Thomas, who is a programmer. Therefore, they invited him to the project as a lead developer (CTO is you will).

At that time I was working as a React front-end developer in the same company where Thomas did. So when he offered me a post of the front-end developer in the new project, I gladly accepted it.

Thomas is a cool buddy, but, to my surprise, he had significantly less experience in web than I did (his specialty has been robotics). But his level of influence and responsibility in the project was far greater than mine (no surprise though, unlike me, Thomas had his skin in the game).

So this is where the things became "interesting". BUT, before blaming others, I want to highlight my own programming mistakes in that project. So let's finally get started!

Front-end

And we'll start from the client part of the web application. Since, as I've already said, I was a front-end developer, this is where I did have power of taking technical decisions.

Since the very beginning we chose React as the primary framework for our front-end. Maybe it was because humans are bad in predicting the future, or maybe I just wasn't smart enough, but I didn't bother with selecting a React platform and simply went with create-react-app.

After some time, when our front-end grew a bit, it became clear that there is a lot of routing logic (of course, our e-commerce application was never meant to be a one-pager!). I then understood that it would be way more efficient to go with something like Next.js to handle that heavy routing. Luckily, the Reach Router I applied to the front-end was good enough to satisfy our routing needs.

(As an excuse at this point I can say that although create-react-app might not be the best choice for our front-end, it was working just fine. With some extra political will it wouldn't be too hard to move it to Next.js, and it would neither be necessary to rewrite the Reach Router stuff right away. We'd be able to do that gradually.)

The next topic was the user interface. No surprise that it was my job to convert that beautiful UI sketches our designer provided to us into responsive and cross-browser markup. It was time to choose a UI library, and I went with Bootstrap. Everything was going good, I was developing the markup page after page, section after section. I even started to override the default Bootstrap theme to match our specific design.

Then it was time for dynamic elements, such as toggleable sidebar menu for mobile screens, for example. The truth is that when it comes to dynamic UI elements, you almost end up with something React-specific like Material UI instead of generic Bootstrap. Thus, I introduced another dependency to our front-end...

Till that moment a lot of markup code had already been written in Bootstrap. What I could do was to declare all the Bootstrap code as legacy and to forbid the team to write new code on Bootstrap. The long-term plan was to gradually replace the Bootstrap code with Material UI and eventually remove the Bootstrap dependency. It never happened, but only because there were a lot of more serious problems in the project than the Bootstrap vs Material UI stuff, so nobody ~~really cared about~~ noticed that.

Finally, another mistake I take 100% responsibility for was not going with TypeScript since the very beginning. The data of our e-commerce application had a very much defined structure, so it was a no-brainer to eventually include TypeScript to our toolchain. Luckily, create-react-app provides an easy way to add TypeScript to an existing application.

And you have already guessed what I decided to do with previously written vanilla JavaScript code: declared it as legacy and started a campaign of gradual replacing that code with Typescript. And yeah, I can confidently claim that most of the vanilla JavaScript code has been replaced with TypeScript till the moment when I left the project.

Back-end

Now it's time for some hardcore }:)

At the beginning of the development of our project there were only two people in the dev team: our tech lead Thomas and me. Early on we split our coding responsibilities by a simple principle: front-end for me, back-end for him. Despite his not so rich experience with web, Thomas has had some knowledge of AWS, so it was a logical step for him to pick AWS as a back-end infrastructure for our project.

Initially Thomas didn't share the details about our back-end with me, nor I thought that was necessary. In fact, I trusted his back-end skills.

But what was happening at that stage was while I was successfully completing my front-end milestones, I was periodically hearing Thomas complaining about his struggles with the back-end part. And not because of laziness at all: it became usual for me watching his red eyes craving to close during our video calls. But I still had no idea what was going on with back-end. What actually happened was that Thomas sold his soul to AWS Amplify.

(Not to blame him though. In fact, all of us must pass through this circle of hell due to the lack of experience. I just did that somewhat earlier than him.)

However, I still didn't rush myself to take a look at the back-end. So Thomas took a decision to involve more people to the project. Thus, two new men joined our team: Alex and Barry.

I have known Alex from another project where we used to work together, so he responded to my invitation for a position of the second front-end developer in the project. Actually I won't say much about Alex, he must be the wisest person in our team because he's the only one I can't blame in anything :D

The tough guy Barry had always had in Thomas's eyes a reputation of a super savvy back-end dev and (what will become important later on) a god of Google Cloud Platform.

In the meanwhile, I realized that our application was becoming brittle without proper quality assurance. It became clear that it was impossible to write meaningful end-to-end tests on Cypress without integration with real back-end. This is when I went out of my front-end capsule and faced the AWS Amplify devil.

The first thing I didn't like was that all our back-end logic was split into modules (product, order, user etc) so each module was deployed to an AWS Lambda. It was still not that bad since each of the Lambda modules was written in plain Express (although even then there was no acceptable way to run the back-end logic on localhost).

Then Barry suddenly announced: "We are now going to write our back-end code in NestJS!". I didn't have anything against NestJS, but I was wondering how they were going to split a monolithic NestJS app into Lambdas, as we had it in Express.

Even though it resulted to be only one Lambda for the entire NestJS server, maybe I don't understand something, but man, functions are not meant for that! Not to mention that it became much harder to run the server on a local machine.

This is when I started to talk about changing our back-end infrastructure. Thomas wanted to stay within AWS, but we couldn't find a better deployment method for the NestJS back-end on the platform (write in comments your furious objections to this right now!). So I told the team: "It is not going to perform well this way. If you want to stay with Amplify so much I vote for sticking with Express for back-end instead of NestJS."

Right below that Slack comment of mine Alex wrote: "I have worked with NestJS, it is awesome! I vote for NestJS!". Sorry, Alex, I lied a couple of paragraphs above, I'm still blaming you :)

But that was not the only problem with AWS Amplify. Because Amplify's primary evil is its heavy configuration. We ended up having more configuration code committed in our repository that the feature code. We were spending more time f@cking with the configuration than actually developing things. And we still could not make the Cypress tests running within Amplify, I am not even sure if the TypeScript decorators stuff of NestJS eventually worked...

Alongside with Amplify, another evil thing of AWS is DynamoDB. And I'm not even talking about its vendor lock-in model. The DynamoDB API itself is probably the most disgusting API I've even seen.

(What I did like in AWS, however, is Cognito. It is OAuth2 compliant, its SDK supports both in-browser login as well as popup/redirect to the authorization server (see OAuth 2.0 specs). And, unlike my favourite Auth0, it doesn't send plain user password via the network!)

Threatened by all this AWS stuff, I started to look for better alternatives. Thomas had always wanted to stay within a single cloud platform for not having to bother with too many accounts. Long story short, between GCP and Azure I chose the latter due to some factors that are beyond this story since we never applied Azure to our project.

What is important is that I had no doubts that switching to Azure will benefit our project, and was trying to explain that to Thomas. I managed to create an Azure account, deployed our front-end there so it was partially working (after all, I spent only 1 evening for that).

Thomas refused to consider all that, he didn't want to take such risk. As he told me some months later: "I thought you were just a front-end guy. I thought you didn't know how to do all that, otherwise I wouldn't be so stubborn.".

Thomas, however, was not the only resistant one. The mastermind Barry also continued to struggle with Amplify, despite his experience in GCP. As for me, during the next 1.5 months there was enough front-end tasks for me which allowed me to distance from the back-end for this time.

After the mentioned 1.5 months passed, I see Thomas posting in Slack: "Barry has moved our project to Google Cloud Platform, team get ready for a group call where he'll explain us about the new infrastructure."

Oh really? So when I was talking about switching the infrastructure, nobody wanted to listen, but when Barry on his own took the decision to move to GCP, it has suddenly become welcomed? What that means, guys, is that eventually I was right, and you just wasted 1.5 months of the project time. I took that personally (not proud of that though), and told Thomas that I was leaving the project. Thomas, however, convinced me to stay.

By staying in the project, I agreed to the new GCP rules. Barry took care of all the deployment and infrastructure processes. Our NestJS server could now be run locally. Nevertheless, after getting known with GCP, I understood that I was right in choosing Azure.

We used Firebase Authentication to work with users, and it worked just fine. I was even able to perform a fancy trick with it in order to close a ticket. The disadvantage of the Firebase Authentication is that it is not OAuth-compliant, which ultimately means vendor lock-in for a project. However, that didn't affect our development work.

The things were harder with Firestore. Similarly to DynamoDB, it is a proprietary DBMS which means what? Right, the vendor lock-in. And this time it made its impact on our work. Firestore has its own SDK for Node.js with its API, which is, however, not as horrible as the one of DynamoDB. Still, due to being proprietary, Firestore doesn't have decent development tools (e.g. ORMs) to simplify developers' lives. You can even agrue with me right now claiming that there are ORMs for Firestore. But they definitely can't be as good as the ones targeting open DBMS like MongoDb or MySQL (let's take Prisma, for example).

Another consequence of using Firestore is having to run the Firebase Emulators on a local machine, since it was the only way to work with the proprietary Firestore locally during our NestJS server development. However, the emulators simulate not just Firestore, but other Firebase services as well. And I have to admit that in case of the Authentication it was quite convenient to work with it locally, unlike it would be possible with Auth0.

There were a couple of other services applied to our project, like mailing or file storage. I can't judge anything about those since I almost didn't work on those parts.

Now, some of you might argue with me since many paragraphs ago: if we were developing an e-commerce application, why the hell did we develop a custom server instead of applying something like headless BigCommerce or Shopify, or at least leveraging Vendure? And you are absolutely damn right! Moreover, I'm taking my part of responsibility for this counter-productive decision. However, if we did that right since the beginning, would we now have such an extensive overview of the popular development tools? ;)

And you, what is your experience in selecting right or wrong tools for web development? Share your stories in the comments!

Also, don't forget to leave your reaction to this article and hit that "Follow" button!

Don't stop coding, don't stop growing!

How to design the architecture of your next web app?

Anton Bahurinsky — Fri, 18 Feb 2022 11:26:10 +0000

So you've got a new contract about developing a brand new web application, your client has provided the technical requirements to you. You have also chosen the development stack for you future programming masterpiece: e.g. React for the client, Node.js for the server, perhaps a DBMS etc.

Now your task is simple: not to kill the web application before it is even born by avoiding mistakes in critical design decisions.

So where to start this process?

This first thing you must understand at this point is that the primary object your web application works with is data.

The data usually has its predefined structure. For example, if you are developing a new e-commerce application, you know that there will be products, cart items, orders and so on, and each product, for example, will have its title, price, description, image list etc.

This is how you usually define the structure of your data, and this is where it gets split into entities.

Thus, defining data entities is the first step of designing the architecture of your future application, since an entity within the app defines:

a module on the React client;
a module on the Node.js server;
a table/collection in the database;
an end-to-end test (manual or automated).

All these compose a logical module (or feature) of your application. So now, when you have defined your first module, you know where and how to start the development process.

It is also worth noting that data entities (and respectively the modules) may depend on each other. Therefore, defining dependencies between modules (and avoiding circular dependencies, of course) will help you to prioritize development tasks. And if you have a team of developers, this will also help you to split the tasks between them.

Hope this article was useful for you. Give a like to this post and hit that "Follow" button!

Don't stop coding, don't stop growing!