Маємо для вас невеличке оновлення! 🫣
Ми знаємо, що в нас зібралось багато талановитих та досвідчених розробників. Також ми знаємо, що у вас точно є чим поділитись з іншими - технології, які ви вивчаєте, складні завдання, які ви змогли вирішити, і просто професійний досвід. Тому, ми хочемо бути тим місцем, де ви зможете легко це зробити!
Як це буде відбуватись?
Ви надсилаєте свій пост до нас в @web_overflow_support і ми будемо публікувати його в канал. Звичайно, він може підлягатись невеличкому редагуванню і перевірці на актуальність. Пости будуть маркуватись хештегом #post_from, після якого буде вказано ваш нік в телеграмі.
Навіщо це нам?
Ми ніколи не приховували, що ми не є експертами в усіх технологіях світу. І не рідко ми бачимо запити від підписників, які хочуть матеріали по фреймворкам, які ми в очі не бачили. А нам хочеться, щоб цей блог приносив користь всім!
Тому давайте ділитись знаннями та розвиватись разом! 💛
Ми знаємо, що в нас зібралось багато талановитих та досвідчених розробників. Також ми знаємо, що у вас точно є чим поділитись з іншими - технології, які ви вивчаєте, складні завдання, які ви змогли вирішити, і просто професійний досвід. Тому, ми хочемо бути тим місцем, де ви зможете легко це зробити!
Як це буде відбуватись?
Ви надсилаєте свій пост до нас в @web_overflow_support і ми будемо публікувати його в канал. Звичайно, він може підлягатись невеличкому редагуванню і перевірці на актуальність. Пости будуть маркуватись хештегом #post_from, після якого буде вказано ваш нік в телеграмі.
Навіщо це нам?
Ми ніколи не приховували, що ми не є експертами в усіх технологіях світу. І не рідко ми бачимо запити від підписників, які хочуть матеріали по фреймворкам, які ми в очі не бачили. А нам хочеться, щоб цей блог приносив користь всім!
Тому давайте ділитись знаннями та розвиватись разом! 💛
🔥20👍8❤3🤯1
C# Moq + SponsorLink 🤯
#post_from @Digicat
Тут буде трохи про C# (ще те збоченство), але думаю буде цікаво для всіх. І нагадуємо, що кожен може розповісти про щось цікаве через наш канал.
Нещодавно в спільноті C# була активна дискусія щодо бібліотеки Moq. Вона дуже популярна для тестування, адже дозволяє підмінювати обʼєкти.
В один момент автор цієї бібліотеки додав всередину іншу - SponsorLink. Ця бібліотека інтегрує GitHub Sponsors у ваш проект та на build етапі сканує залежності і пропонує вам стати спонсором інших open-source проектів. Ви навіть отримаєте warning, якщо не підтримуєте жоден проект.
Інтегрування цієї бібліотеки в Moq була несподіваною. На додачу, SponsorLink використовував ваш email та тримав його хеш в хмарі, про що нікого не попереджав. Власне це і стало рушієм всіх обговорень..
👉 Читати статтю
Також тут варто згадати про faker.js, який минулого року теж наробив шуму.
👉 Дивитись відео
Тож питання щодо OSS досі не вирішені. В них сотні мільйонів скачувань, а автори підтримують їх. Тож як вирішити спонсорування цих авторів? Яку участь в цьому мають брати мільярдні компанії, які використовують цей код?
#post_from @Digicat
Тут буде трохи про C# (ще те збоченство), але думаю буде цікаво для всіх. І нагадуємо, що кожен може розповісти про щось цікаве через наш канал.
Нещодавно в спільноті C# була активна дискусія щодо бібліотеки Moq. Вона дуже популярна для тестування, адже дозволяє підмінювати обʼєкти.
В один момент автор цієї бібліотеки додав всередину іншу - SponsorLink. Ця бібліотека інтегрує GitHub Sponsors у ваш проект та на build етапі сканує залежності і пропонує вам стати спонсором інших open-source проектів. Ви навіть отримаєте warning, якщо не підтримуєте жоден проект.
Інтегрування цієї бібліотеки в Moq була несподіваною. На додачу, SponsorLink використовував ваш email та тримав його хеш в хмарі, про що нікого не попереджав. Власне це і стало рушієм всіх обговорень..
👉 Читати статтю
Також тут варто згадати про faker.js, який минулого року теж наробив шуму.
👉 Дивитись відео
Тож питання щодо OSS досі не вирішені. В них сотні мільйонів скачувань, а автори підтримують їх. Тож як вирішити спонсорування цих авторів? Яку участь в цьому мають брати мільярдні компанії, які використовують цей код?
👍6❤2
NestJS + Telegram Bot API
#post_from @Yurets7777 @urbfkfys
Багато хто чув або вже знає, що таке є той NestJS. І звісно всі знають, що таке Телеграм і Телеграм-Боти. Хтось чув, хтось пробував щось писати з допомогою Telegram Bot API або NestJS.
Даний пост про те - а як правильно запустити телеграм бота на NestJS?
Не можу сказати що це просто.
Як рекомендує NestJS, створюємо окрему директорію для нашого телеграм бота під назвою
І всі запити до нашої БД, котрі вміють робити дані сервіси, буде вміти робити наш ТГ-бот. Потрібно просто прописати необхідні методи з даних класів в сервісі телеграму.
Ну і звісно модуль, куди ж без нього 🤷
Ліба для запуску Телеграм-Бота на NestJS називається
Корисні посилання:
- NestJS
- NestJS Telegraf
- Telegram Bot API
PS. Ми тут робимо щось дійсно цікаве на даних технологіях. Скоро очікуйте Український продукт 😉
PPS. Забули показати root компонент app.module.ts
Поки все 😉
#post_from @Yurets7777 @urbfkfys
Багато хто чув або вже знає, що таке є той NestJS. І звісно всі знають, що таке Телеграм і Телеграм-Боти. Хтось чув, хтось пробував щось писати з допомогою Telegram Bot API або NestJS.
Даний пост про те - а як правильно запустити телеграм бота на NestJS?
Не можу сказати що це просто.
Як рекомендує NestJS, створюємо окрему директорію для нашого телеграм бота під назвою
telegram
. В ній, по класиці, нам потрібні: module
- telegram.module.ts
; controller
- telegram.controller.ts
; service
- telegram.service.ts
.telegram.service.ts
- це те, що відповідає за запити до нашої БД. Сюди ми підтягуємо інші сервіси, щоб ТГ-бот вмів працювати із різними сутностями в нашій БД.@Injectable()
export class TelegramService {
constructor(
private userService: UserService,
private categoryService: CategoryService,
private cityService: CityService,
) {}
}
І всі запити до нашої БД, котрі вміють робити дані сервіси, буде вміти робити наш ТГ-бот. Потрібно просто прописати необхідні методи з даних класів в сервісі телеграму.
telegram.controller.ts
- контроллер; сама назва говорить сама за себе - контролюю. Сюди ми підтягуємо наш телеграм сервіс. Прописуємо команди, прослуховувачі на екшени (кліки на кнопки) та інше.@Update()
export class TelegramController {
private readonly telegramActions: TelegramActions;
constructor(
@InjectBot() private readonly bot: Telegraf<Context>,
private readonly telegramService: TelegramService,
) {
this.bot.telegram.setMyCommands(COMMANDS);
this.telegramActions = new TelegramActions(this.telegramService);
}
@Start()
async startCommand(ctx): Promise<any> {
// do something
}
@Command(my_command)
async addLotCommand(ctx): Promise<any> {
// do something
}
@Action(String || RegEx)
async handleRejectLot(ctx): Promise<any> {
// do something
}
}
Ну і звісно модуль, куди ж без нього 🤷
telegram.module.ts
- модуль збирає в себе все що потрібно для запуску нашої app, в даному випадку бота.@Module({
imports: [
ConfigModule.forRoot({
envFilePath: '.env', // для того щоб була змога читати змінні із env
}),
TelegrafModule.forRoot({
middlewares: [session()],
token: process.env.TELEGRAM_BOT_TOKEN, //
не має сенсу в коментарях
}),
UserModule,
CategoryModule,
CityModule,
],
controllers: [],
providers: [
TelegramService,
TelegramController,
RegisterUserScene,
],
})
export class TelegramModule {}
Ліба для запуску Телеграм-Бота на NestJS називається
nestjs-telegraf
. Якщо хочете конкретики, запитуйте. Що знаємо - підкажемо 😉Корисні посилання:
- NestJS
- NestJS Telegraf
- Telegram Bot API
PS. Ми тут робимо щось дійсно цікаве на даних технологіях. Скоро очікуйте Український продукт 😉
PPS. Забули показати root компонент app.module.ts
@Module({
imports: [
ConfigModule.forRoot({
envFilePath: '.env',
}),
MongooseModule.forRoot(process.env.MONGO_CONNECTION_STRING),
UserModule,
TelegramModule,
CategoryModule,
],
controllers: [AppController],
providers: [AppService],
})
export class AppModule {}
Поки все 😉
👍21❤5👏3🔥1
BullMQ - продвинутий cron для NodeJS 💪
#post_from @Yurets7777 @urbfkfys
Що таке "cron"?
Cron - це утиліта для планування завдань у багатьох операційних системах, зокрема в Unix і подібних до неї, таких як Linux. Вона дозволяє користувачам створювати розклади для виконання автоматичних завдань, які будуть виконуватися регулярно або за заданим графіком. BullMQ - це бібліотека Node.js, яка реалізує швидку та надійну систему черг, побудовану на основі Redis, що допомагає у роботі багатьом сучасним мікросервісним архітектурам.
Бібліотека розроблена таким чином, щоб виконувати наступні завдання:
- встановлення черги "рівно один раз", тобто спроби зробити кожну дію рівно один раз. Кожна дія буде виконана принаймні один раз або більше, в залежності від встановлених параметрів;
- легке масштабування по горизонталі. Додайте більше "воркерів" для паралельної обробки завдань;
- послідовність;
- висока продуктивність.
А тепер простими словами!
Потрібно виконати певні дії із певною затримкою або певним інтервалом. Що перше спадає на думку?
Так, розумні хостери типу Heroku це побачать і перезапустять build. Але … наша черга чи інтервал пішов по одному місцю 🤦♀️
І тут нам на допомогу приходять такі от ліби, як BullMQ. Це прям ДУЖЕ крутий комбайн, але під капотом він юзає redis. Сюди він зберігає всі екшени, які повинні відпрацювати. Саме тому, коли код крашнеться і перезапуститься, ліба піде в rdb (redis data base) і продовжить свою роботу, а не почне спочатку, як у випадку із таймаутом.
Як то працює?
Спочатку необхідно створити чергу.
У дану чергу додаються воркери - це, скажімо так, методи (функції) котрі всередині можуть містити інші методи (функції), котрі повинні відпрацювати, коли прийшла черга роботи даного воркера.
А тепер час "подружити" наш воркер із чергою 😉
Вітаємо, ви створили cron, який 100% виконає те, що ви вказали, і стільки раз скільки потрібно 😎
Дока нижче 😉
👉 Відкрити документацію
#post_from @Yurets7777 @urbfkfys
Що таке "cron"?
Cron - це утиліта для планування завдань у багатьох операційних системах, зокрема в Unix і подібних до неї, таких як Linux. Вона дозволяє користувачам створювати розклади для виконання автоматичних завдань, які будуть виконуватися регулярно або за заданим графіком. BullMQ - це бібліотека Node.js, яка реалізує швидку та надійну систему черг, побудовану на основі Redis, що допомагає у роботі багатьом сучасним мікросервісним архітектурам.
Бібліотека розроблена таким чином, щоб виконувати наступні завдання:
- встановлення черги "рівно один раз", тобто спроби зробити кожну дію рівно один раз. Кожна дія буде виконана принаймні один раз або більше, в залежності від встановлених параметрів;
- легке масштабування по горизонталі. Додайте більше "воркерів" для паралельної обробки завдань;
- послідовність;
- висока продуктивність.
А тепер простими словами!
Потрібно виконати певні дії із певною затримкою або певним інтервалом. Що перше спадає на думку?
setTimeout
та setInterval
. Логічно 🤔, рухаємося далі. А якщо сервер крашнеться або код "посипеться"?Так, розумні хостери типу Heroku це побачать і перезапустять build. Але … наша черга чи інтервал пішов по одному місцю 🤦♀️
І тут нам на допомогу приходять такі от ліби, як BullMQ. Це прям ДУЖЕ крутий комбайн, але під капотом він юзає redis. Сюди він зберігає всі екшени, які повинні відпрацювати. Саме тому, коли код крашнеться і перезапуститься, ліба піде в rdb (redis data base) і продовжить свою роботу, а не почне спочатку, як у випадку із таймаутом.
Як то працює?
Спочатку необхідно створити чергу.
async function createQueue(queueName: string) {
try {
const queue = new Queue(queueName);
return queue;
} catch (error) {
console.log("[error]", error);
}
}
У дану чергу додаються воркери - це, скажімо так, методи (функції) котрі всередині можуть містити інші методи (функції), котрі повинні відпрацювати, коли прийшла черга роботи даного воркера.
const worker = new Worker("queueName", async (job) => {
const {
// тут все, що ви закинули у воркер в дані
} = job.data;
// тут ваш пейлоад, котрий має доступ до даних, які ви закинули у воркер
});
А тепер час "подружити" наш воркер із чергою 😉
await queue.add(
"queueName",
{ /* закидаємо нашу дату для воркера */ },
{
jobId: someJobId, // унікальний id джоби, щоб вони не задвоїлися
// інші параметри як то ріпіт чи once
}
);
Вітаємо, ви створили cron, який 100% виконає те, що ви вказали, і стільки раз скільки потрібно 😎
Дока нижче 😉
👉 Відкрити документацію
👍17🔥4❤3🤓2
Welcome!
#post_from @ihor_888 😅
Let's practice our English! So...
👉 Tell us about the music you listen to while coding.
Have a nice #english_friday 💛
#post_from @ihor_888 😅
Let's practice our English! So...
👉 Tell us about the music you listen to while coding.
Have a nice #english_friday 💛
👍9❤1🔥1😁1😱1🤣1
Локалізація app-ок в micro Front-End 🤯
Поки ми серйозно заганяємось, вже традиційно ловіть
#post_from @Yurets7777 @urbfkfys
Останнім часом нас трохи занесло в оцей весь micro Front-End. Ми розробляємо окремі модулі powered by ReactJS, котрі вбудовуються в батьківську App (CRM, яка також на ReactJS).
Ми вирішили поділитися тим, як ми це зробили і написали для вас статтю. Винесли її в Notion і щоб було веселіше - додали приклади з кодом.
👉 Відкрити статтю
Поки ми серйозно заганяємось, вже традиційно ловіть
#post_from @Yurets7777 @urbfkfys
Останнім часом нас трохи занесло в оцей весь micro Front-End. Ми розробляємо окремі модулі powered by ReactJS, котрі вбудовуються в батьківську App (CRM, яка також на ReactJS).
Ми вирішили поділитися тим, як ми це зробили і написали для вас статтю. Винесли її в Notion і щоб було веселіше - додали приклади з кодом.
👉 Відкрити статтю
👍14❤3🔥2🤓1
Давайте поговоримо про деплой …
Для того щоб не скидати замовникам посилання на localhost, ловіть
#post_from @Yurets7777
Деплой - простими словами це розгортання і запуск проекту на хостингу/сервері.
Поділюся своїм хоч і невеликим експірієнсом і враженнями.
🌍 Звичайний хостинг
Тут говорити особо нічого. Мав декілька кейсів:
1. Хостинг із підтримкою NodeJS. Запускав там фронт. Великий мінус - не було зв’язку із GitHub репозиторієм, відповідно всі зміни в коді потрібно було закидати по FTP.
2. Тут взагалі все було просто як пробка. Робимо локально build React App і туда його на хостинг. Жабаскрипт зібраний, до index.html підключений, що ще потрібно? 🤷 Не цікаво, але дешево і сердито.
🌍 Виділений віртуальний сервер
Ще часто фігурують скорочення типу VDS / VPS.
Це був практично найперший досвід деплоя full-stack javascript app на “голій” Ubuntu. Орендував у одного із Українських хостерів близько ~ $10 / місяць.
Мінуси:
⁃ Довго налаштовувати під себе. Для того щоб просто стартонути прийшлося навісити NodeJS, додаткові приблуди для запуску, щоб запустити Back та Front, прикрутити SSL сертифікати. Це щоб просто запуститися без зайвих обвісів;
⁃ Коли app падає, потрібно піднімати руками, перезапускати. Або городити ще щось зверху;
Плюс лише один:
⁃ робиш під себе все що хочеш, в рамках дозволених правилами хостингу.
🌍 Vercel - деплой фронтової частини апки
Взагалі не Верселем єдиним, є і інші схожі сервіси. Але мені сподобався даний сервіс.
Плюси:
⁃ адекватні безкоштовні ліміти;
⁃ автодеплой із GitHub репозиторію. Пряма зав’язка за допомогою якої, не потрібно руками налаштовувати GitHub Actions. Пуш у продакшн гілку запускає автоматичний деплой;
⁃ прив’язка свого домена (адекватна інструкція how to);
Мінуси:
⁃ бува підтуплює на халявному тарифному плані.
🌍 Heroku - деплой back-end
Раніше був безкоштовним, наразі став платним, але воно того вартує.
Плюси:
⁃ адекватні тарифи, звичайний щось ~ $7/місяць (виділяється певна к-сть годин, якщо мені памʼять не зраджує). Разом із тим є еко-тариф за $5/місяць (певна к-сть робочих годин). На еко-тарифі сервак спить до першого запиту, через це перший запит відпрацьовує із деяким затупом, а потім все як положено. Якщо запитів не має, апп-ка знову засинає;
⁃ автодеплой із GitHub репозиторія. Пряма зав’язка за допомогою якої, не потрібно руками налаштовувати GitHub Actions. Пуш у продакшн гілку запускає автоматичний деплой;
⁃ коли програма падає, Хероку відловлює критичні помилки і самостійно перезапускає build;
Мінуси:
⁃ Не зручно масштабувати.
Потрібно ще AWS пощупати. Поки дорогувато і не має потреби. Але там цікаво реалізоване масштабування інстансів програми.
Наразі все.
Для того щоб не скидати замовникам посилання на localhost, ловіть
#post_from @Yurets7777
Деплой - простими словами це розгортання і запуск проекту на хостингу/сервері.
Поділюся своїм хоч і невеликим експірієнсом і враженнями.
🌍 Звичайний хостинг
Тут говорити особо нічого. Мав декілька кейсів:
1. Хостинг із підтримкою NodeJS. Запускав там фронт. Великий мінус - не було зв’язку із GitHub репозиторієм, відповідно всі зміни в коді потрібно було закидати по FTP.
2. Тут взагалі все було просто як пробка. Робимо локально build React App і туда його на хостинг. Жабаскрипт зібраний, до index.html підключений, що ще потрібно? 🤷 Не цікаво, але дешево і сердито.
🌍 Виділений віртуальний сервер
Ще часто фігурують скорочення типу VDS / VPS.
Це був практично найперший досвід деплоя full-stack javascript app на “голій” Ubuntu. Орендував у одного із Українських хостерів близько ~ $10 / місяць.
Мінуси:
⁃ Довго налаштовувати під себе. Для того щоб просто стартонути прийшлося навісити NodeJS, додаткові приблуди для запуску, щоб запустити Back та Front, прикрутити SSL сертифікати. Це щоб просто запуститися без зайвих обвісів;
⁃ Коли app падає, потрібно піднімати руками, перезапускати. Або городити ще щось зверху;
Плюс лише один:
⁃ робиш під себе все що хочеш, в рамках дозволених правилами хостингу.
🌍 Vercel - деплой фронтової частини апки
Взагалі не Верселем єдиним, є і інші схожі сервіси. Але мені сподобався даний сервіс.
Плюси:
⁃ адекватні безкоштовні ліміти;
⁃ автодеплой із GitHub репозиторію. Пряма зав’язка за допомогою якої, не потрібно руками налаштовувати GitHub Actions. Пуш у продакшн гілку запускає автоматичний деплой;
⁃ прив’язка свого домена (адекватна інструкція how to);
Мінуси:
⁃ бува підтуплює на халявному тарифному плані.
🌍 Heroku - деплой back-end
Раніше був безкоштовним, наразі став платним, але воно того вартує.
Плюси:
⁃ адекватні тарифи, звичайний щось ~ $7/місяць (виділяється певна к-сть годин, якщо мені памʼять не зраджує). Разом із тим є еко-тариф за $5/місяць (певна к-сть робочих годин). На еко-тарифі сервак спить до першого запиту, через це перший запит відпрацьовує із деяким затупом, а потім все як положено. Якщо запитів не має, апп-ка знову засинає;
⁃ автодеплой із GitHub репозиторія. Пряма зав’язка за допомогою якої, не потрібно руками налаштовувати GitHub Actions. Пуш у продакшн гілку запускає автоматичний деплой;
⁃ коли програма падає, Хероку відловлює критичні помилки і самостійно перезапускає build;
Мінуси:
⁃ Не зручно масштабувати.
Потрібно ще AWS пощупати. Поки дорогувато і не має потреби. Але там цікаво реалізоване масштабування інстансів програми.
Наразі все.
👍31❤5🤓2
Як відправити SMS повідомлення | 2fa
#post_from @Yurets7777 @urbfkfys
В чаті іноді з’являються запитання: а як, а де?
Тому why not, погнали 😉
Раптом хтось вірив в чудо, нажаль 🤷 чуда не має, і sms-повідомлення відправляються за допомогою сторонніх сервісів. Саме про такі сервіси і піде мова нижче.
По-перше, де, для чого і як (поки що❗️) то юзається?
⁃ 2fa - двох-факторна автентифікація (раджу почитати про автентифікацію та авторизацію);
⁃ промо sms-розсилки;
⁃ Підтвердження замовлення, etc.
Важливо розуміти, що для подібних сервісів необхідно зареєструвати відправника. Тобто не можна просто слати що попало від кого заманеться. Разом із тим, зазвичай в кожному сервісі по відправці sms повідомлень є тестові відправники та певна к-сть безкоштовних sms для тесту.
TurboSMS
👉 Дока тут
Насправді взагалі нічого складного. Реєструємося, отримуємо токен даного сервісу.
Шлемо запит методом
При цьому в
eSputnik
Ці трішки постаралися і зробили
Також, ну само собою, потрібен
Twilio - один із любимчиків поза межами наших ланів широкополих
Мають свій пакет в
Даний сервіс видає такі ідентифікатори:
⁃ Account SID;
⁃ Auth Token;
⁃ Ну і звісно можна зарегати тестового відправника;
SMS-ки триндець які дорогі тут 😥
Бонус плюс, як реалізувати 2fa via sms
Фронт шле запит на бек типу, давай генеруй разовий код.
Бек генерує разовий пароль, приміром рандоматіком.
Зберігає його в БД та відправляє sms - повідомлення на вказаний номер телефону.
Задається ttl (час життя даного одноразового коду). На фронті, в ідеалі, тікає таймер.
Користувач отримує sms-повідомлення із паролем, вводить його на фронті.
Фронт відправляє на бек. Бек апрувить і далі виконує необхідні дії.
Ось так все просто відбувається за кадром.
До нових зустрічей!
PS: Не забувайте зберігати важливі дані користувача (паролі, токени) у безпеці та в зашифрованому вигляді 😉
#post_from @Yurets7777 @urbfkfys
В чаті іноді з’являються запитання: а як, а де?
Тому why not, погнали 😉
Раптом хтось вірив в чудо, нажаль 🤷 чуда не має, і sms-повідомлення відправляються за допомогою сторонніх сервісів. Саме про такі сервіси і піде мова нижче.
По-перше, де, для чого і як (поки що❗️) то юзається?
⁃ 2fa - двох-факторна автентифікація (раджу почитати про автентифікацію та авторизацію);
⁃ промо sms-розсилки;
⁃ Підтвердження замовлення, etc.
Важливо розуміти, що для подібних сервісів необхідно зареєструвати відправника. Тобто не можна просто слати що попало від кого заманеться. Разом із тим, зазвичай в кожному сервісі по відправці sms повідомлень є тестові відправники та певна к-сть безкоштовних sms для тесту.
TurboSMS
👉 Дока тут
Насправді взагалі нічого складного. Реєструємося, отримуємо токен даного сервісу.
Шлемо запит методом
POST
по даному енд-поінту: https://api.turbosms.ua/message/send.json
При цьому в
header
кладемо наш токен, а в body
необхідні параметри:headers['Authorization'] = TOKEN;
body = {
sender, // Відправник
recipients, // Отримувачі (номери телефонів типу string)
text: message, // Тест sms повідомлення
sms: {}, // Залежно від того, який тип повідомлення необхідно надіслати, в тілі запиту повинні бути присутні параметри viber або sms, або обидва, для гибридної відправки.
};
eSputnik
Ці трішки постаралися і зробили
sdk
.const sdk = require('api')('@esputnik-com/v1.0#3ztkwwleradipt');
Також, ну само собою, потрібен
API
ключ)await sdk.auth(userLogin, "API-Key");
await sdk.sendSMS(
{
from: sender,
phoneNumbers: recipients,
text: message,
},
{ accept: "application/json; charset=UTF-8" }
);
Twilio - один із любимчиків поза межами наших ланів широкополих
Мають свій пакет в
npm
.const client = require("twilio")(SID, token);
await client.iss.onessages.create({
body: message,
from: sender,
to: +${recipients[0]}, // варто вказувати “+” перед номером відправника
});
Даний сервіс видає такі ідентифікатори:
⁃ Account SID;
⁃ Auth Token;
⁃ Ну і звісно можна зарегати тестового відправника;
SMS-ки триндець які дорогі тут 😥
Бонус плюс, як реалізувати 2fa via sms
Фронт шле запит на бек типу, давай генеруй разовий код.
Бек генерує разовий пароль, приміром рандоматіком.
Зберігає його в БД та відправляє sms - повідомлення на вказаний номер телефону.
Задається ttl (час життя даного одноразового коду). На фронті, в ідеалі, тікає таймер.
Користувач отримує sms-повідомлення із паролем, вводить його на фронті.
Фронт відправляє на бек. Бек апрувить і далі виконує необхідні дії.
Ось так все просто відбувається за кадром.
До нових зустрічей!
PS: Не забувайте зберігати важливі дані користувача (паролі, токени) у безпеці та в зашифрованому вигляді 😉
👍23❤6🔥3🤓1
Імплементуємо кросс-проектний DRY 🤔
#post_from @Yurets7777
Кажуть, що полюбляють на співбесідах запитувати про DRY (don’t repeat yourself). В межах одного проекту то звісно всім все зрозуміло. А якщо одні і ті ж методи використовуються в різних проектах? Наприклад, сервіс для відправки смс-повідомлень або ж сервіс для обробки онлайн платежів тощо. Тобто скрізь однакова логіка під ваші задачі.
Отак і у нас постало питання, щоб винести однотипну логіку в одне місце для перевикористання між різними проектами.
Перше, що ми зробили, це просто окремий GitHub репозиторій. В ньому загальні сервіси із необхідними методами. Підключається такий репо до іншого проекту так само, як і npm пакет:
Таким чином, необхідні сервіси та залежності підтягнуться із даного репо. Трабл, з яким ми зіткнулися - репозиторії то приватні 🤦 і під час деплою наш
Оскільки в нас вже були готові загальні сервіси, ми просто їх "сконвертували" в повноцінний npm-пакет. Це діло 5 - 10 хвилин.
А як то робиться - 👉 читайте тут
Токен - Авторизація - Публікуємо.
Нюанси:
- для публікації приватних npm пакетів необхідно оформити підписку. Але ніхто не обмежує в публікації публічних пакетів 😉
- кожна нова публікація пакету це зміна версії програми в package.json. Не важливо мінорна версія чи мажорна, головне оновити версію перед публікацією.
Профіт колосальний, універсальні сервіси із чистими функціями, котрі юзаються кросс-проектно. Внесення змін в коді лише в одному місці. Щоб запрацював оновлений код у всіх інших проектах, достатньо просто оновити свій npm пакет в необхідному проекті 🤟
#post_from @Yurets7777
Кажуть, що полюбляють на співбесідах запитувати про DRY (don’t repeat yourself). В межах одного проекту то звісно всім все зрозуміло. А якщо одні і ті ж методи використовуються в різних проектах? Наприклад, сервіс для відправки смс-повідомлень або ж сервіс для обробки онлайн платежів тощо. Тобто скрізь однакова логіка під ваші задачі.
Отак і у нас постало питання, щоб винести однотипну логіку в одне місце для перевикористання між різними проектами.
Перше, що ми зробили, це просто окремий GitHub репозиторій. В ньому загальні сервіси із необхідними методами. Підключається такий репо до іншого проекту так само, як і npm пакет:
"common-services": "а_тут_посилання_на_потрібний_репозиторій"
Таким чином, необхідні сервіси та залежності підтягнуться із даного репо. Трабл, з яким ми зіткнулися - репозиторії то приватні 🤦 і під час деплою наш
"common-services"
не підтягнув код із нашого ж приватного репо. Тому такий підхід підійде для публічних репозиторіїв. А якщо хтось знає як розшарити доступи до таких репо при деплої, welcome у коментарі 👇Оскільки в нас вже були готові загальні сервіси, ми просто їх "сконвертували" в повноцінний npm-пакет. Це діло 5 - 10 хвилин.
А як то робиться - 👉 читайте тут
Токен - Авторизація - Публікуємо.
Нюанси:
- для публікації приватних npm пакетів необхідно оформити підписку. Але ніхто не обмежує в публікації публічних пакетів 😉
- кожна нова публікація пакету це зміна версії програми в package.json. Не важливо мінорна версія чи мажорна, головне оновити версію перед публікацією.
Профіт колосальний, універсальні сервіси із чистими функціями, котрі юзаються кросс-проектно. Внесення змін в коді лише в одному місці. Щоб запрацював оновлений код у всіх інших проектах, достатньо просто оновити свій npm пакет в необхідному проекті 🤟
👍11❤6👨💻2❤🔥1
Query Management Philosophy In Salesforce 😎
#post_from @JS_us
Salesforce - дуже потужний інструмент для ведення бізнесу. У статті розглянуто Salesforce Query Manager та те, чому автор рекомендує його використовувати.
👉 Читати статтю
#post_from @JS_us
Salesforce - дуже потужний інструмент для ведення бізнесу. У статті розглянуто Salesforce Query Manager та те, чому автор рекомендує його використовувати.
👉 Читати статтю
👍5❤2🔥1
Web text-editor ✍️
#post_from @vova_taras
Кожен frontend розробник має свій маленький список страхів. І багато в кого в цьому списку можна знайти таку страшилку як wysiwyg або ж rich text editor. Адже реалізовувати в себе в проекті урізану копію Google Docs навряд чи приємно.
Така ситуація спіткала і мене, тому довелося шукати підходящі інструменти. Одразу на думку спала DraftJS, авторам якої є Facebook, або ще точніше - React Draft Wysiwyg, що є обгорткою над DraftJS для використання в React. Її використовували в проектах мої знайомі та колеги, тому я вирішив розглянути цей варіант. Так як бібліотека не оновлювалась вже більше року, я вирішив перевірити в якому стані знаходиться DraftJS. Виявилось, що Facebook архівував цей репозиторій в лютому цього року. Тобто не буде додано нічого нового, а з багів будуть виправлені тільки critical security.
Проте, якщо глянути трохи нижче, зможете знайти секцію, в якій сказано, що Meta працює над міграцією на інший інструмент - Lexical. Це новий проект, який має активно підтримуватись. Тому, зараз важко говорити про досвід його використання, але перше враження склалось хороше, адже він може використовуватись і на чистому JS, і має певні обгортки на React. Також тут є підтримка різних плагінів, наприклад, історія змін.
Варто додати, що фреймворк не надає повністю готових компонент (наприклад Toolbar та кнопки взаємодії з редактором). Їх потрібно реалізовувати самим, використовуючи API, яке надає фреймворк. Документація відчувається сирою і не все очевидно, тому варто також звертати увагу на статті з Інтернету та відео в YouTube.
👉 Відкрити репозиторій
#post_from @vova_taras
Кожен frontend розробник має свій маленький список страхів. І багато в кого в цьому списку можна знайти таку страшилку як wysiwyg або ж rich text editor. Адже реалізовувати в себе в проекті урізану копію Google Docs навряд чи приємно.
Така ситуація спіткала і мене, тому довелося шукати підходящі інструменти. Одразу на думку спала DraftJS, авторам якої є Facebook, або ще точніше - React Draft Wysiwyg, що є обгорткою над DraftJS для використання в React. Її використовували в проектах мої знайомі та колеги, тому я вирішив розглянути цей варіант. Так як бібліотека не оновлювалась вже більше року, я вирішив перевірити в якому стані знаходиться DraftJS. Виявилось, що Facebook архівував цей репозиторій в лютому цього року. Тобто не буде додано нічого нового, а з багів будуть виправлені тільки critical security.
Проте, якщо глянути трохи нижче, зможете знайти секцію, в якій сказано, що Meta працює над міграцією на інший інструмент - Lexical. Це новий проект, який має активно підтримуватись. Тому, зараз важко говорити про досвід його використання, але перше враження склалось хороше, адже він може використовуватись і на чистому JS, і має певні обгортки на React. Також тут є підтримка різних плагінів, наприклад, історія змін.
Варто додати, що фреймворк не надає повністю готових компонент (наприклад Toolbar та кнопки взаємодії з редактором). Їх потрібно реалізовувати самим, використовуючи API, яке надає фреймворк. Документація відчувається сирою і не все очевидно, тому варто також звертати увагу на статті з Інтернету та відео в YouTube.
👉 Відкрити репозиторій
👍15❤3🔥1😱1
Jam 🍓
#post_from @vova_taras
Ніхто не запамʼятає вас за круті фічі, які ви додали на проєкт, проте вони памʼятатимуть кожен ваш баг. І тут є два виходи - обізвати його фічею або ж просто пофіксити його. Давайте поговоримо про варіант №2.
Вам сильно пощастило, якщо у вас є тестувальник. Вам вдвічі пощастило, якщо він толковий. Щоб відтворити якусь проблему та виправити її часто потрібно багато вхідних даних. І тут вам може допомогти Jam. Це розширення для Chrome, яке дуже просто дозволить QA чи замовнику (якщо він виконує роль QA) швидко відзвітувати про проблему. Тут автоматично зберігається інформація про девайс, браузер, логи в консолі та запити в мережі. І мені здається, що ця інформація точно не буде зайвою.
👉️️ Відкрити посилання
#post_from @vova_taras
Ніхто не запамʼятає вас за круті фічі, які ви додали на проєкт, проте вони памʼятатимуть кожен ваш баг. І тут є два виходи - обізвати його фічею або ж просто пофіксити його. Давайте поговоримо про варіант №2.
Вам сильно пощастило, якщо у вас є тестувальник. Вам вдвічі пощастило, якщо він толковий. Щоб відтворити якусь проблему та виправити її часто потрібно багато вхідних даних. І тут вам може допомогти Jam. Це розширення для Chrome, яке дуже просто дозволить QA чи замовнику (якщо він виконує роль QA) швидко відзвітувати про проблему. Тут автоматично зберігається інформація про девайс, браузер, логи в консолі та запити в мережі. І мені здається, що ця інформація точно не буде зайвою.
👉️️ Відкрити посилання
👍17❤4🔥3
#post_from @MatiGreen
#todo написати функцію на будь-якій мові програмування, яка приймає натуральне число та повертає рядок тексту - число конвертоване у римську систему числення.
Наприклад:
* завдання з зірочкою - написати функцію, яка виконує зворотню конвертацію.
#todo написати функцію на будь-якій мові програмування, яка приймає натуральне число та повертає рядок тексту - число конвертоване у римську систему числення.
Наприклад:
3 => III
14 => XIV
192 => CXCII
* завдання з зірочкою - написати функцію, яка виконує зворотню конвертацію.
❤6👍3🔥2🤔2
#post_from @Taraskin777
Допоки React Compiler ще не готовий, варто дбати про оптимізацію своїх React-застосунків власноруч. Тому, якщо вам потрібно вдосконалити продуктивність вашого React-сайту, вам допоможе стаття на сайті DOU.
👉 Читати статтю
Допоки React Compiler ще не готовий, варто дбати про оптимізацію своїх React-застосунків власноруч. Тому, якщо вам потрібно вдосконалити продуктивність вашого React-сайту, вам допоможе стаття на сайті DOU.
👉 Читати статтю
👍10❤3🔥2🥰1🎉1
Чи можливо зробити ChatGPT-7? 🤯
#post_from @neanime
Наш друг написав дуже цікаву статтю, в якій детально розглянув ключові виклики та потенційні рішення для майбутньої розробки ChatGPT-7. Чи є можливість створення цієї нової версії, і які саме шляхи вона може прокласти у світі штучного інтелекту?
👉 Відкрити посилання
Всіх запрошуємо до прочитання! 💛
#post_from @neanime
Наш друг написав дуже цікаву статтю, в якій детально розглянув ключові виклики та потенційні рішення для майбутньої розробки ChatGPT-7. Чи є можливість створення цієї нової версії, і які саме шляхи вона може прокласти у світі штучного інтелекту?
👉 Відкрити посилання
Всіх запрошуємо до прочитання! 💛
👍12❤4🔥1
Tailwind Variants 🧣
#post_from @vova_taras
Tailwind Variants - бібліотека, яка з допомогою Tailwind класів дозволяє будувати API для різних варіацій стилів. Вона має різний функціонал, як, наприклад, розширення стилів чи розділення їх на слоти.
👉 Відкрити посилання
#library
#post_from @vova_taras
Tailwind Variants - бібліотека, яка з допомогою Tailwind класів дозволяє будувати API для різних варіацій стилів. Вона має різний функціонал, як, наприклад, розширення стилів чи розділення їх на слоти.
👉 Відкрити посилання
#library
👍5❤3👀1
Deno 2 🦖
#post_from @vova_taras
Deno існує вже досить давно, але супер-великої популярності він не здобув, адже мав низку проблем/мінусів. Одним з них була відсутність підтримки npm-пакетів. Але ось нещодавно творець Node.js та Deno представив Deno версії 2, в якій ця проблема була вирішена.
Окрім цього, серед нового тут підтримка моно-репозиторіїв, повна підтримка TypeScript з коробки, стабільна стандартна бібліотека. Вам не потрібен форматувальник, лінтер чи бібліотека для тестування. Тож, загалом, зараз Deno, здається, повністю готовий для використання в проєктах. Звісно, ще купу всього вилізе, але, можливо, через це і цікаво побачити, що буде далі.
Ну і для ознайомлення, додаємо відео від Fireship.
👉 Відкрити посилання
#news
#post_from @vova_taras
Deno існує вже досить давно, але супер-великої популярності він не здобув, адже мав низку проблем/мінусів. Одним з них була відсутність підтримки npm-пакетів. Але ось нещодавно творець Node.js та Deno представив Deno версії 2, в якій ця проблема була вирішена.
Окрім цього, серед нового тут підтримка моно-репозиторіїв, повна підтримка TypeScript з коробки, стабільна стандартна бібліотека. Вам не потрібен форматувальник, лінтер чи бібліотека для тестування. Тож, загалом, зараз Deno, здається, повністю готовий для використання в проєктах. Звісно, ще купу всього вилізе, але, можливо, через це і цікаво побачити, що буде далі.
Ну і для ознайомлення, додаємо відео від Fireship.
👉 Відкрити посилання
#news
👍6❤5😁2
Driver.js 🚖
#post_from @vova_taras
На багатьох веб-сайтах можна побачити підказки у вигляді інтерактивних підсвічувань кнопок чи форм. Такий гід по сайту може значно полегшити ознайомлення з функціоналом.
Driver.js — бібліотека, яка дозволяє легко створити подібний тур по вашому продукту, підкреслюючи ключові елементи. Краще один раз побачити, ніж десять разів прочитати, тож перегляньте демо-тур на офіційному сайті driver.js.
👉Відкрити посилання
#library
#post_from @vova_taras
На багатьох веб-сайтах можна побачити підказки у вигляді інтерактивних підсвічувань кнопок чи форм. Такий гід по сайту може значно полегшити ознайомлення з функціоналом.
Driver.js — бібліотека, яка дозволяє легко створити подібний тур по вашому продукту, підкреслюючи ключові елементи. Краще один раз побачити, ніж десять разів прочитати, тож перегляньте демо-тур на офіційному сайті driver.js.
👉Відкрити посилання
#library
👍14❤5🔥3
Nice Modal 💅
#post_from @vova_taras
Робота з модальними вікнами в React може бути доволі дратівливою. Потрібно тримати стан (
@ebay/nice-modal-react використовує трохи інший підхід до роботи з модальними вікнами. Ви можете просто викликати функцію
Також великим плюсом є робота через
👉 Відкрити посилання
#library
#post_from @vova_taras
Робота з модальними вікнами в React може бути доволі дратівливою. Потрібно тримати стан (
isOpen
) і продумати способи закривання (як із зовнішньої компоненти, так і всередині самого вікна).@ebay/nice-modal-react використовує трохи інший підхід до роботи з модальними вікнами. Ви можете просто викликати функцію
show
та передати в неї компонент із пропсами. Це не зовсім декларативний метод, але, на нашу думку, значно зручніший.Також великим плюсом є робота через
Promise
. Якщо у вас коли-небудь було модальне вікно для підтвердження, і потрібно було передавати колбеки для onConfirm
та onCancel
, тепер можна просто повернути значення з функції виклику.const modal = useModal(ConfirmationModal)
const onDelete = async () => {
const confirmed = await modal.show({text: "Are you sure?"})
if (confirmed) {
...
}
}
👉 Відкрити посилання
#library
👍12🔥3❤2