ಕ್ರೋನ್ ಜಾಬ್‌ಗಳಲ್ಲಿ ನಕಲಿ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ತಡೆಯುವುದು ಹೇಗೆ

ಸಾಫ್ಟ್‌ವೇರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಕಾರ್ಯಗಳು ಸುಗಮವಾಗಿ ಮತ್ತು ನಕಲಿಯಾಗದೆ ರನ್ ಆಗುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ. ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿನ ಒಂದು ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ನಾವು ಚರ್ಚಿಸುತ್ತಿದ್ದೇವೆ: ಇನ್-ಪ್ರೊಸೆಸ್ ಶೆಡ್ಯೂಲರ್ ರಾತ್ರಿಯ ಜಾಬ್ ಅನ್ನು ಹೇಗೆ ಅನೇಕ ಬಾರಿ ರನ್ ಮಾಡಲು ಕಾರಣವಾಗಬಹುದು, ಇದು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಕಲಿ ರೆಕಾರ್ಡ್‌ಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಹೆಚ್ಚು ಕಂಪನಿಗಳು ಮೈಕ್ರೋಸರ್ವಿಸಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುತ್ತಿರುವುದರಿಂದ, ಸೇವೆಗಳು ಅಡ್ಡಲಾಗಿ ಸ್ಕೇಲ್ ಆಗುವಾಗ ಈ ವಿಷಯವು ವಿಶೇಷವಾಗಿ ಪ್ರಸ್ತುತವಾಗಿದೆ.

ಸೆಟಪ್

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಸಕ್ರಿಯ ಎಂಟಿಟಿಗಳಿಗಾಗಿ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ರಚಿಸುವ ರಾತ್ರಿಯ ಜಾಬ್ ಅನ್ನು ನೀವು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಈ ಜಾಬ್ ದಿನಕ್ಕೊಮ್ಮೆ ರನ್ ಆಗಬೇಕು, ಪ್ರತಿ ಎಂಟಿಟಿಗೆ ಒಂದು ಹೊಸ ರೆಕಾರ್ಡ್ ಅನ್ನು ರಚಿಸಬೇಕು. ಸರ್ವರ್-ಸೈಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಜನಪ್ರಿಯ ಫ್ರೇಮ್‌ವರ್ಕ್ ಆದ NestJS ಅನ್ನು ಬಳಸುವ ವಿಶಿಷ್ಟ ಸೆಟಪ್‌ನಲ್ಲಿ, ನೀವು ಇದನ್ನು ಬಳಸಬಹುದು @Cron ಈ ಜಾಬ್ ಅನ್ನು ನಿಗದಿಪಡಿಸಲು ಡೆಕೊರೇಟರ್. ಅದು ಹೇಗಿರಬಹುದು ಎಂಬುದರ ಸರಳೀಕೃತ ಆವೃತ್ತಿ ಇಲ್ಲಿದೆ:

@Injectable()
export class WindowGenerationService {
    @Cron('0 8 * * *') // every day at 08:00
    async generateNextWindows() {
        const entities = await this.repo.findActiveEndingSoon();
        for (const entity of entities) {
            await this.repo.createNextWindow(entity);
        }
    }
}

ನಿಮ್ಮ ಸೇವೆಯ ಒಂದೇ ಇನ್ಸ್ಟನ್ಸ್ ರನ್ ಆಗುತ್ತಿರುವಾಗ ಈ ಕೋಡ್ ಸಂಪೂರ್ಣವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಬಹು ಇನ್ಸ್ಟನ್ಸ್‌ಗಳನ್ನು ಚಾಲನೆ ಮಾಡುವ ಮೂಲಕ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಡ್ಡಲಾಗಿ ಸ್ಕೇಲ್ ಮಾಡಿದಾಗ, ವಿಷಯಗಳು ತಪ್ಪಾಗಬಹುದು.

ಸಮಸ್ಯೆ

ಸ್ಕೇಲ್ಡ್ ಸೆಟಪ್‌ನಲ್ಲಿ, ನಿಮ್ಮ ಸೇವೆಯ ಮೂರು ಇನ್ಸ್ಟನ್ಸ್‌ಗಳನ್ನು ನೀವು ಹೊಂದಿದ್ದರೆ, ಪ್ರತಿಯೊಂದು ಇನ್ಸ್ಟನ್ಸ್ ನಿಗದಿತ ಜಾಬ್‌ನ ತನ್ನದೇ ಆದ ಪ್ರತಿಯನ್ನು ಒಂದೇ ಸಮಯದಲ್ಲಿ ರನ್ ಮಾಡುತ್ತದೆ. ಆದ್ದರಿಂದ, 08:00 ಕ್ಕೆ ಒಂದು ಜಾಬ್ ರನ್ ಆಗುವ ಬದಲು, ಏಕಕಾಲದಲ್ಲಿ ಮೂರು ಜಾಬ್‌ಗಳು ರನ್ ಆಗುತ್ತವೆ. ಪ್ರತಿಯೊಂದು ಇನ್ಸ್ಟನ್ಸ್ ಅವು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸದೆ ತನ್ನದೇ ಆದ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ. ಇದು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಕಲಿ ನಮೂದುಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಒಂದೇ ಎಂಟಿಟಿಗಾಗಿ ಎರಡು ಒಂದೇ ರೀತಿಯ ರೆಕಾರ್ಡ್‌ಗಳು ಸೆಕೆಂಡುಗಳ ಅಂತರದಲ್ಲಿ ರಚನೆಯಾಗುತ್ತವೆ.

ಇದು ಏಕೆ ಮುಖ್ಯ

ನಕಲಿ ಡೇಟಾವು ಡೇಟಾ ಸಮಗ್ರತೆಯ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ವ್ಯರ್ಥ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ವಿವಿಧ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ನೀವು ಅನಗತ್ಯ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ರಚಿಸುವುದು ಮಾತ್ರವಲ್ಲದೆ, ಒಂದೇ ಕೆಲಸವನ್ನು ಮಾಡುವ ಮೂರು ಕಂಟೇನರ್‌ಗಳ ಕಂಪ್ಯೂಟ್ ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ನೀವು ಪಾವತಿಸುತ್ತಿದ್ದೀರಿ.

ಸಂಭವನೀಯ ಪರಿಹಾರಗಳು

ಸಮಸ್ಯೆಯನ್ನು ಗುರುತಿಸಿದ ನಂತರ, ಅದನ್ನು ಪರಿಹರಿಸಲು ಹಲವಾರು ಮಾರ್ಗಗಳಿವೆ:

ಆಯ್ಕೆ 1: ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಲಾಕ್ ಬಳಸಿ

ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಲಾಕ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಒಂದು ಪರಿಹಾರವಾಗಿರಬಹುದು. ಇದು ಇನ್ಸ್ಟನ್ಸ್‌ಗಳಿಗೆ ಲಾಕ್‌ಗಾಗಿ ಸ್ಪರ್ಧಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಕೇವಲ ಒಂದು ಇನ್ಸ್ಟನ್ಸ್‌ಗೆ ಜಾಬ್ ರನ್ ಮಾಡಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಈ ವಿಧಾನವು ತನ್ನದೇ ಆದ ನ್ಯೂನತೆಗಳನ್ನು ಹೊಂದಿದೆ. ಲಾಕ್ ಬ್ಯಾಕೆಂಡ್ ವಿಫಲವಾದರೆ ಅಥವಾ ಲಾಕ್ ಅನ್ನು ಹೊಂದಿರುವಾಗ ಇನ್ಸ್ಟನ್ಸ್ ಸ್ಥಗಿತಗೊಂಡರೆ, ಜಾಬ್ ರನ್ ಆಗದಿರಬಹುದು, ಇದು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ತಪ್ಪಿಹೋಗಲು ಕಾರಣವಾಗುತ್ತದೆ.

ಆಯ್ಕೆ 2: ಐಡೆಂಪೊಟೆನ್ಸಿ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ

ಐಡೆಂಪೊಟೆನ್ಸಿ ಚೆಕ್ ಅನ್ನು ಸೇರಿಸುವುದು ಇನ್ನೊಂದು ಆಯ್ಕೆಯಾಗಿದೆ. ಅಂದರೆ ಜಾಬ್ ಮತ್ತೆ ರನ್ ಆದರೆ, ಅವು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ರಚಿಸುವುದನ್ನು ಅದು ಸರಳವಾಗಿ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ಇದು ಅಗ್ಗದ ಪರಿಹಾರವಾಗಿದ್ದರೂ, ಇದು ಇನ್ನೂ ಎಲ್ಲಾ ಇನ್ಸ್ಟನ್ಸ್‌ಗಳನ್ನು ಎಚ್ಚರಗೊಳಿಸುತ್ತದೆ, ಇದು ಅನಗತ್ಯ ಕೆಲಸಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಆಯ್ಕೆ 3: ಶೆಡ್ಯೂಲಿಂಗ್ ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊರಗೆ ಸರಿಸಿ

ಕಂಡುಬಂದಂತೆ, ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಶೆಡ್ಯೂಲಿಂಗ್ ಅನ್ನು ಹೊರತೆಗೆಯುವುದು ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ. ಜಾಬ್‌ಗಳು ಯಾವಾಗ ರನ್ ಆಗಬೇಕು ಎಂಬುದನ್ನು ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ವಹಿಸುವ ಬದಲು, ಅದನ್ನು ಬಾಹ್ಯ ಶೆಡ್ಯೂಲರ್ ನಿಭಾಯಿಸಲು ಬಿಡಿ. ಈ ರೀತಿಯಾಗಿ, ನಿಗದಿತ ಸಮಯದಲ್ಲಿ ಬಾಹ್ಯ ಶೆಡ್ಯೂಲರ್ ಒಮ್ಮೆ ಟ್ರಿಗರ್ ಮಾಡುವ HTTP ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ನೀವು ರಚಿಸಬಹುದು. ಅದು ಹೇಗಿರಬಹುದು ಎಂಬುದು ಇಲ್ಲಿದೆ:

@Post('jobs/run')
async runJob(@Body() body: RunJobDto) {
    this.assertValidSecret(body.secret);
    return this.jobs.run(body.jobKey);
}

ಈ ಸೆಟಪ್‌ನೊಂದಿಗೆ, ನಕಲಿ ರೆಕಾರ್ಡ್‌ಗಳು ರಚನೆಯಾಗುವುದನ್ನು ತಡೆಯುವ ಮೂಲಕ ಕೇವಲ ಒಂದು ಇನ್ಸ್ಟನ್ಸ್ ಜಾಬ್ ಟ್ರಿಗರ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಜಾಬ್ ಅನ್ನು ಅನೇಕ ಬಾರಿ ಟ್ರಿಗರ್ ಮಾಡಿದರೂ ಸಹ ಅದು ನಕಲುಗಳನ್ನು ರಚಿಸುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಐಡೆಂಪೊಟೆನ್ಸಿ ಚೆಕ್ ಹಾಗೆಯೇ ಇರುತ್ತದೆ.

ಇದರ ವೆಚ್ಚವೇನು

ನೀವು ಜಾಬ್ ಅನ್ನು HTTP ಎಂಡ್‌ಪಾಯಿಂಟ್ ಆಗಿ ಬಹಿರಂಗಪಡಿಸಿದಾಗ, ನೀವು ಭದ್ರತೆಯನ್ನು ಪರಿಗಣಿಸಬೇಕು. ಈ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಹುಡುಕುವ ಯಾರಾದರೂ ಅದನ್ನು ಸಂಭಾವ್ಯವಾಗಿ ಟ್ರಿಗರ್ ಮಾಡಬಹುದು. ಅನಧಿಕೃತ ಪ್ರವೇಶವನ್ನು ತಡೆಗಟ್ಟಲು, ವಿನಂತಿಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸಲು ಹಂಚಿಕೆಯ ರಹಸ್ಯವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಕೇವಲ ನ್ಯಾಯಸಮ್ಮತ ಟ್ರಿಗರ್‌ಗಳು ಮಾತ್ರ ಜಾಬ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಲ್ಲವು ಎಂದು ಇದು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ಪರಿಗಣಿಸಬೇಕಾದ ಇನ್ನೊಂದು ವಿಷಯವೆಂದರೆ ನಿಗದಿತ ಸಮಯ. ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ದಿನದ ಪ್ರಾರಂಭದ ನಂತರ ಜಾಬ್ ರನ್ ಆಗಬೇಕು, ಬಹು ಸಮಯ ವಲಯಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುವಾಗ ಇದು ಕಷ್ಟಕರವಾಗಿರಬಹುದು. ಸ್ಥಿರವಾದ UTC ಗಂಟೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದರಿಂದ ವಿವಿಧ ಪ್ರದೇಶಗಳಲ್ಲಿ ಇದನ್ನು ಪ್ರಮಾಣೀಕರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಪಾಠ

ಈ ಅನುಭವವು ಒಂದು ನಿರ್ಣಾಯಕ ಪಾಠವನ್ನು ಎತ್ತಿ ತೋರಿಸುತ್ತದೆ: ಇನ್-ಪ್ರೊಸೆಸ್ ಶೆಡ್ಯೂಲರ್ ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಅನಿರೀಕ್ಷಿತ ನಡವಳಿಕೆಗೆ ಕಾರಣವಾಗಬಹುದು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವಾಗ, ಅಪ್ಲಿಕೇಶನ್ ಲಾಜಿಕ್‌ನಿಂದ ಶೆಡ್ಯೂಲಿಂಗ್ ಕಾಳಜಿಯನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ಅತ್ಯಗತ್ಯ. ಹಾಗೆ ಮಾಡುವುದರಿಂದ, ನೀವು ನಕಲಿ ರೈಟ್‌ಗಳ ಅಪಾಯಗಳನ್ನು ತಪ್ಪಿಸಬಹುದು ಮತ್ತು ನಿಮ್ಮ ಜಾಬ್‌ಗಳು ಉದ್ದೇಶಿಸಿದಂತೆ ರನ್ ಆಗುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು.

ತೀರ್ಮಾನ

ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಮೈಕ್ರೋಸರ್ವಿಸಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಕ್ರೋನ್ ಜಾಬ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಎಚ್ಚರಿಕೆಯ ಯೋಜನೆ ಅಗತ್ಯವಿದೆ. ಶೆಡ್ಯೂಲಿಂಗ್ ಅನ್ನು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊರಗೆ ಸರಿಸುವ ಮೂಲಕ ಮತ್ತು ಸರಿಯಾದ ಪರಿಶೀಲನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೂಲಕ, ನೀವು ನಕಲಿ ರೆಕಾರ್ಡ್‌ಗಳಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ತಡೆಯಬಹುದು ಮತ್ತು ನಿಮ್ಮ ಸೇವೆಗಳ ದಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸಬಹುದು.

ಪ್ರಯೋಜನಗಳು

• ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಕಲಿ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ತಡೆಯುತ್ತದೆ.
• ಅನಗತ್ಯ ಕಂಪ್ಯೂಟ್ ವೆಚ್ಚಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
• ಶೆಡ್ಯೂಲಿಂಗ್ ಅನ್ನು ಹೊರಗೆ ಸರಿಸುವ ಮೂಲಕ ಜಾಬ್ ನಿರ್ವಹಣೆಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ.

ಅನಾನುಕೂಲಗಳು

• ಬಾಹ್ಯ ಶೆಡ್ಯೂಲರ್‌ಗಾಗಿ ಹೆಚ್ಚುವರಿ ಸೆಟಪ್ ಅಗತ್ಯವಿದೆ.
• HTTP ವಿನಂತಿಗಳು ಮತ್ತು ಭದ್ರತೆಯನ್ನು ನಿಭಾಯಿಸುವಲ್ಲಿ ಸಂಕೀರ್ಣತೆಯನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ.

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನವು ಶೈಕ್ಷಣಿಕ ಅವಲೋಕನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಯಾವುದೇ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಮೌಲ್ಯಗಳನ್ನು ನಿಮ್ಮ ನಿಜವಾದ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಲು ಮರೆಯದಿರಿ ಮತ್ತು ಅವುಗಳನ್ನು ಅವಲಂಬಿಸುವ ಮೊದಲು ಮೂಲದ ವಿರುದ್ಧ ಕ್ಲೈಮ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• ಕ್ರೋನ್ ಜಾಬ್ ಎಂದರೇನು? — ಕ್ರೋನ್ ಜಾಬ್ ಎಂಬುದು ನಿಗದಿತ ಮಧ್ಯಂತರಗಳಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರನ್ ಆಗುವ ನಿಗದಿತ ಕಾರ್ಯವಾಗಿದೆ.
• ನನ್ನ ಕ್ರೋನ್ ಜಾಬ್ ಅನೇಕ ಬಾರಿ ಏಕೆ ರನ್ ಆಯಿತು? — ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಬಹು ಇನ್ಸ್ಟನ್ಸ್‌ಗಳಲ್ಲಿ ಜಾಬ್ ಅನ್ನು ನಿಗದಿಪಡಿಸಿದ್ದರೆ ಇದು ಸಂಭವಿಸಬಹುದು.
• ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಕಲಿ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ನಾನು ಹೇಗೆ ತಡೆಯಬಹುದು? — ಐಡೆಂಪೊಟೆನ್ಸಿ ಚೆಕ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ ಅಥವಾ ಶೆಡ್ಯೂಲಿಂಗ್ ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊರಗೆ ಸರಿಸಿ.
• ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಲ್ಲಿ ಐಡೆಂಪೊಟೆನ್ಸಿ ಎಂದರೇನು? — ಐಡೆಂಪೊಟೆನ್ಸಿ ಎಂದರೆ ಆರಂಭಿಕ ಅಪ್ಲಿಕೇಶನ್‌ನ ಆಚೆಗೆ ಫಲಿತಾಂಶವನ್ನು ಬದಲಾಯಿಸದೆ ಫಂಕ್ಷನ್ ಅನ್ನು ಅನೇಕ ಬಾರಿ ಕರೆಯಬಹುದು.
• NestJS ಎಂದರೇನು? — NestJS ಎಂಬುದು ದಕ್ಷ, ಸ್ಕೇಲೆಬಲ್ Node.js ಸರ್ವರ್-ಸೈಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ಫ್ರೇಮ್‌ವರ್ಕ್ ಆಗಿದೆ.
• ನನ್ನ HTTP ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ನಾನು ಹೇಗೆ ಭದ್ರಪಡಿಸುವುದು? — ವಿನಂತಿಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸಲು ಹಂಚಿಕೆಯ ರಹಸ್ಯಗಳು ಅಥವಾ ಟೋಕನ್‌ಗಳಂತಹ ದೃಢೀಕರಣ ವಿಧಾನಗಳನ್ನು ಬಳಸಿ.

ಟ್ಯಾಗ್‌ಗಳು

#cron #nestjs #microservices #scheduling #softwareengineering #dataintegrity #cloudcomputing #distributedsystems