taxonomy VS Nest

I am building this app with inspiration from Taxonomy and Acme corp so a lot of the design comes from there.

View on GitHub

Now, I must confess that I'm primarily a back-end engineer, and crafting a beautiful front-end was, well, a bit of an adventure. To keep things straightforward, I opted for simplicity. I figured I could enhance it as my customer base grew, as the real value, of course, lies in the robustness of the API and its backend. Looking back, I might consider using a template like https://tx.shadcn.com/ if I were to start all over again. It appears to be a great starting point for any SaaS, but the setup might pose some challenges.

Check out these two GitHub repositories: https://github.com/sadmann7/skateshop/ and https://github.com/shadcn/taxonomy/. They both use Next.js 13 and have well-structured folders and well-written code. Next.js provides performance optimization. To improve it further, avoid loading unnecessary items and use a CDN for fast content delivery. Both not loading unnecessary content & lazy loading) and CDN is 2 individual topics to dive into.

I've also been inspired by this repo, but the Vercel template seems more achievable for me at this point.

In addition to the repository I mentioned in my original post, I've also been inspired by another repository (Taxonomy Repo) which has implemented a similar Stripe integration. However, this one is a bit more complex and I'm finding the Vercel template to be more achievable for my current skill level.

I'm currently working on a Next.js project where I'm trying to integrate Stripe for payments and webhooks. I've been following the Taxonomy GitHub repo for guidance, particularly for setting up the app router and the lib files.

When using the NestJS framework, sometimes you may need to change some default timeout. You can define them just like you'd do in a plain Node.js HTTP server like so:

Back: a graphQL server built with Nestjs

NestJS - opinionated more scalable, but harder to learn docs

Pragmatically, we can apply this to a Nest application by creating an Interface for our services, separating the Presenter layer (Controller) from the Use Case (Services):

It’s a text document that contains all the commands a user could call to assemble an image. Let’s check an example of a Dockerfile for a nodejs app in this case it will be a NestJS app and then explain each part.

describe('Create bookmarks', () => { const dto: CreateBookmarkDto = { title: 'NestJS', link: 'https://nestjs.com/', }; it('should create bookmark', () => { return pactum .spec() .post('/bookmarks') .withHeaders({ Authorization: 'Bearer $S{userAt}', }) .withBody(dto) .expectStatus(201) .stores('bookmarkId', 'id')//store the bookmark id in the variable bookmarkId .expectBodyContains(dto.title) .expectBodyContains(dto.link) }); });

In my usual NodeJS tech stack, which includes GraphQL, NestJS, SQL (predominantly PostgreSQL with MikroORM), I encountered these limitations. To overcome them, I've developed a new stack utilizing Rust, which still offers some ease of development:

The purpose of this article is to provide a step-by-step guide for implementing authentication system in a NestJS project using the Passport middleware module.

That's exactly where I am. My manager gave me these links, that cover a lot of those words the backend uses, so I can identify what they mean and how to use them. 1. For inspiration and concepts: https://github.com/Sairyss/domain-driven-hexagon 2. Suggested to read the documentation for nest.js. They apply such concepts I don't understand: https://nestjs.com/