Я понимаю такую реакцию, многие ошибки действительно элементарные, и у людей подгорает когда они видят, что я работаю в Гугле, у них эти две вещи совмещаются и начинаются сомнения в моей компетенции))
У проекта широкий контекст, который в статье сложно раскрыть: его делало много людей, много месяцев, там много функционала, и я не писал лично все эти вещи, и даже не я в основном их ревьювил, я был в роли Fractional CTO на этом проекте и делал так, чтобы выпуск случился, и чтобы всё работало.
Но, опять же, прекрасно понимаю всю критику, люди думают, что я рассказал про проект, который сам написал от начала до конца и что все вопросы надо предъявлять мне, потому что кому ещё? Тут же нет контактов тех разрабов, кто конкретно написал findOne в цикле)) Это в целом логично.
Так же в статье самые крупные факапы, тут нет самых крупных крутых решений, которых было много на самом деле, но какой смысл про них рассказывать. Как по мне, ошибки гораздо ценнее. Если мы их сделали, то и другие тоже могут сделать и скорее всего сделают. Ведь ошибки эти часто типовые.
В любом случае, многим это точно будет полезно и многие смогут избежать таких же ошибок. Видно, что такой контент людям интересен. Эту статью уже больше 40 человек добавили в закладки, прошлую - больше 50.
Ваши утверждения либо основаны на устаревших данных, либо это просто рандомные набросы без аргументов.
Разберем по пунктам:
1. SSR
SSR мы в течении пары дней после запуска заменили на SSG. SSR во время релиза там остался по ошибке - я не проверил эту часть перед запуском, а разработчики, которые этим занимались тоже упустили это. Конечно, SSR тут это очень плохо и бессмысленно.
2. NestJS / Express / Fastify
Ваше незнание архитектуры фреймворка очевидно. Вы обвиняете NestJS в плохой производительности, не зная того, что NestJS предоставляетFastifyAdapter, позволяющий заменить Express на движок, который в 4.5 раза быстрее по бенчмаркам. И медленный тут именно Express, а не NestJS, обратите внимание. Миграция требует изменения 3 строк кода без потери функционала DI и модульности.
3. MongoDB vs PostgreSQL
Мы специально выбрали именно MongoDB, потому что у нас часто меняются схемы данных, быстро добавляется новый функционал, убирается старый. Нам проще делать миграции схемы данных с MongoDB, и она отлично подходит под наш сценарий.
У нас почти все операции это простые чтения по ID или простым фильтрам, у нас нет сложных JOIN'ов и требований ACID к транзакциям. Нам нет смысла использовать PostgreSQL на данном этапе проекта.
А ещё MongoDB гораздо проще и эффективнее масштабируется горизонтально.
Опять, какой-то эмоциональный наброс без аргументов.
4. Docker
Исследования IBM демонстрируют, что накладные расходы контейнеризации в Linux составляют <2%. Docker не эмулирует железо — он использует cgroups и namespaces ядра. В эту же тему можно почитать здесь. Для продакшн проектов изоляция зависимостей и воспроизводимость окружения критичнее гипотетических 1-2% потерь.
Если вы заявляете про "20-30% потерь" — это или намеренная дезинформация, или непонимание сути технологии. Перестаньте распространять ваше заблуждение.
Ваши утверждения либо основаны на устаревших данных, либо это просто рандомные набросы без аргументов.
Разберем по пунктам:
1. Docker
Исследования IBM демонстрируют, что накладные расходы контейнеризации в Linux составляют <2%. Docker не эмулирует железо — он использует cgroups и namespaces ядра. В эту же тему можно почитать здесь. Для продакшн проектов изоляция зависимостей и воспроизводимость окружения критичнее гипотетических 1-2% потерь.
Если вы заявляете про "20-30% потерь" — это или намеренная дезинформация, или непонимание сути технологии. Перестаньте распространять ваше заблуждение.
2. NestJS / Fastify
Ваше незнание архитектуры фреймворка очевидно. Вы обвиняете NestJS в плохой производительности, не зная того, что NestJS предоставляетFastifyAdapter, позволяющий заменить Express на движок, который в 4.5 раза быстрее по бенчмаркам. Миграция требует изменения 3 строк кода без потери функционала DI и модульности.
3. MongoDB vs PostgreSQL
Мы специально выбрали именно MongoDB, потому что у нас часто меняются схемы данных, быстро добавляется новый функционал, убирается старый. Нам проще делать миграции схемы данных с MongoDB, и она отлично подходит под наш сценарий.
У нас почти все операции это простые чтения по ID или простым фильтрам, у нас нет сложных JOIN'ов и требований ACID к транзакциям. Нам нет смысла использовать PostgreSQL на данном этапе проекта.
А ещё MongoDB гораздо проще и эффективнее масштабируется горизонтально.
Опять, какой-то эмоциональный наброс без аргументов.
4. NGINX
Спасибо большое за совет, но у нас он и так используется в качестве Reverse Proxy. Тут пустая болтовня.
5. SSR
SSR мы в течении пары дней после запуска заменили на SSG. SSR во время релиза там остался по ошибке - я не проверил эту часть перед запуском, а разработчики, которые этим занимались тоже упустили это. Конечно, SSR тут это очень плохо и бессмысленно.
Резюмируя: выглядит так, что вы всю жизнь сидите на одном стеке с любимым потсгресом, а свои проекты деплоите по FTP (попробуйте CI/CD, не знаю слышали о таком или нет).
Обвинять меня в обмане вы, конечно же, не имеете ни прав, ни оснований. Мои данные открытые и публичные.
По вопросам веры - в церковь.
Ваш заминусованный профиль только подтверждает мои слова, что это просто рандомные набросы, чтобы потешить своё эго. Сегодня не выйдет. По фактам вы уничтожены. Приходите завтра.
На этапе первого запуска мы сознательно выбрали простой и предсказуемый сетап — тот, в котором всё работает именно так, как мы ожидаем, и стоит заранее известную сумму. При этом да, у нас есть единая точка отказа, это не очень надёжно.
Сейчас уже начинаем рассматривать более гибкие решения, похожие на то, что вы описали.
Наш характер нагрузки хорошо под это подходит: чаще всего в приложении онлайн до 500 пользователей, но бывают резкие всплески — когда за несколько секунд заходят 10–15 тысяч человек.
Автоскейлинг и распределение по нескольким зонам доступности действительно сделают систему надёжнее. Возможно, это окажется и дешевле при нашей текущей нагрузке — хотя многое будет зависеть от её характера. Сейчас пики редкие и кратковременные, но уже в следующем футбольном сезоне (через 3 месяца) мы ожидаем изменения.
Мы планируем серьёзные продуктовые доработки и хотим, чтобы пользователи заходили не только во время матчей, но и между ними. Это может привести к росту постоянного онлайна и изменению профиля нагрузки — соответственно, изменятся и расходы.
Я думаю, что ваш подход на текущей нагрузке точно будет надежнее и выгоднее. Но в будущем нужно будет посчитать.
Острой необходимости в SSR нет, и на текущий момент мы уже полностью перешли на SSG, про это будет подробнее во второй части статьи. Вы правы, на счёт того, что фронтенд сервер вообще не нужен, планируем убирать его.
Соглашусь с тем, что несколько миллионов DAU можно держать на таком железе. Поэтому мы его и брали, чтобы был запас. И тут я хотел скорее подчеркнуть именно то, что за такие небольшие деньги можно получить такие мощности, которые позволят держать несколько миллионов DAU.
Мы понимали, что вопрос именно в оптимизациях и корректной конфигурации.
На самом деле, сейчас у нас всё очень комфортно по нагрузке: даже в пиковые моменты фронтенд сервер загружен не больше чем на 4%, а бэкенд — максимум на 18%. Это ситуации когда большой единомоментный трафик, больше чем 15 тысяч пользователей заходят за несколько секунд. А в обычных ситуациях нагрузка на фронт в районе 1%, на бэк - 3%.
Поэтому, не думаю, что есть какая-то проблема в стеке JS + MongoDB.
Запас по ресурсам у нас сейчас приличный, и видно, что есть ещё куда оптимизировать, например, внедрить кэширование уже на уровне бэкенда (пока его у нас нет). Так что вопрос скорее не в стеке, а в том, как его использовать и насколько грамотно всё настроено.
Соглашусь, 100 000 уников за 3 дня это не много. Но, ключевой фактор тут - это характер нагрузки. Есть ярковыраженные вспелски, когда за несколько секунд 10-15 тысяч пользователей одновременно заходят в приложение.
Мы изначально брали сервера с запасом, потому что не было чёткого понимания, сколько реально придёт пользователей. По прогнозам, максимум могло быть до миллиона за три дня, минимум — тысяч 50. В итоге, вышло что-то среднее, но инфраструктуру закладывали именно с прицелом на максимальные значения, чтобы не получить аврал в случае удачного запуска.
VPS за 5 долларов у ноунейм-провайдера, как правило, сильно ограничена по ресурсам. Если вдруг в течение пары секунд в приложение зайдёт 20 тысяч человек — такой сервер просто ляжет, особенно если это не статичный сайт, а динамическое приложение с авторизацией, API и базой данных. Тут вы, мне кажется, немного не учитываете реальные ограничения дешёвых VPS.
Ну и плюс — мы специально брали инфраструктуру с запасом, чтобы потом не возвращаться к этому вопросу через месяц и не заниматься экстренным переносом. Это даёт возможность спокойно развивать продукт, не боясь внезапных всплесков трафика. При этом соглашусь, мы бы могли обойтись серверами не за 200 $, а скажем за 50 $, реалистично. Но разница между этими цифрами не такая уж существенная.
Основной конкурент это spravochnick.ru и znanija.com
Их бизнес-модель работает потому что она у них есть :)
У них она немного разная. Справочник в конечном итоге зарабатывает на комиссии за заказные работы для студентов. Знания продают подписку за безлимитное пользование сервисом.
Они определённо зарабатывают, но мы и не думали пытаться забрать их аудиторию применив их бизнес-модели. Мне кажется справочник зарабатывает гораздо больше, чем знания.
Мы в целом мало думали про бизнес-модель. А то, что у нас было в голове - было про монетизацию не через заказные работы для студентов, а каким-то другим образом.
Спасибо за такой вдумчивый и глубокий комментарий!
Забрасывать не планируем, это точно. Тут уже даже спортивный интерес включается - просто посмотреть как во времени будет развиваться ситуация с органическим трафиком.
И да, вы очень правильно подметили, что зарабатывать на своих продуктах это задача со звёздочкой. Лично я убеждён, что успешный стартап - это вопрос количества попыток. Конечно, нужно учиться на своём и чужом опыте, но всё равно - даже если учесть все ошибки - в следующий раз, скорее всего, возникнут новые.
Не ошибается тот, кто ничего не делает.
Да, касаемо бедных студентов в точку. Мы так и думали. Поэтому наши идеи по монетизации и строились на том, чтобы их сводить с заинтересованными организациями. Такие организации точно есть.
Касаемо корпораций - мы смотрим сейчас в сегмент корпоративного обучения, в формате микрообучения. Кто знает, может быть с этим что-то получится.
Ваша идея интересная. Вы затронули тему того, что нет общепринятой методологии изучения. Согласен с вами. Мне кажется, тут главный вопрос в том, чтобы изобрести именно методологию. Программный продукт, на мой взгляд, здесь второстепенен, он сделается под методологию легко.
Изобрести универсальную методологию по изучению языков самостоятельно, которая подходила бы всем - это не просто. Возможно поэтому её и нет.
Ведь учить язык это более комплексное занятие, чем учить ответы на вопросы, к примеру.
Будет круто, если у вас получится! Подумаю ещё над вашими тезисами.
Нет, это не тотализатор, там только софт валюта и много интерактивных активностей для футбольных фанатов.
Спасибо большое за поддержку!
Я понимаю такую реакцию, многие ошибки действительно элементарные, и у людей подгорает когда они видят, что я работаю в Гугле, у них эти две вещи совмещаются и начинаются сомнения в моей компетенции))
У проекта широкий контекст, который в статье сложно раскрыть: его делало много людей, много месяцев, там много функционала, и я не писал лично все эти вещи, и даже не я в основном их ревьювил, я был в роли Fractional CTO на этом проекте и делал так, чтобы выпуск случился, и чтобы всё работало.
Но, опять же, прекрасно понимаю всю критику, люди думают, что я рассказал про проект, который сам написал от начала до конца и что все вопросы надо предъявлять мне, потому что кому ещё? Тут же нет контактов тех разрабов, кто конкретно написал findOne в цикле)) Это в целом логично.
Так же в статье самые крупные факапы, тут нет самых крупных крутых решений, которых было много на самом деле, но какой смысл про них рассказывать. Как по мне, ошибки гораздо ценнее. Если мы их сделали, то и другие тоже могут сделать и скорее всего сделают. Ведь ошибки эти часто типовые.
В любом случае, многим это точно будет полезно и многие смогут избежать таких же ошибок. Видно, что такой контент людям интересен. Эту статью уже больше 40 человек добавили в закладки, прошлую - больше 50.
У, эйджизм, продолжим обязательно!
Спасибо! Дельный совет, приму на вооружение.
Не все, на самом деле :) В статье я поделился самыми крупными факапами, кому-то это точно будет полезно.
Все эти факапы мы очень быстро решили за несколько дней и первый запуск прошел для нас с большим успехом.
Проект большой, его писало много людей на протяжении многих месяцев, я не мог физически уследить за всем. Прошу понять)
Ожидаемо, что когда делишься факапами — это обязательно привлечёт критику. Ну что ж, я знал на что иду)
Если у вас нигде никогда не бывает факапов, даже самых элементарных, то я вам завидую белой завистью!
Ахахах, спасибо за ваш комментарий. С кайфом почитал, посмеялся, зарядили хорошим настроением!
Успехов!
Ваши утверждения либо основаны на устаревших данных, либо это просто рандомные набросы без аргументов.
Разберем по пунктам:
1. SSR
SSR мы в течении пары дней после запуска заменили на SSG. SSR во время релиза там остался по ошибке - я не проверил эту часть перед запуском, а разработчики, которые этим занимались тоже упустили это. Конечно, SSR тут это очень плохо и бессмысленно.
2. NestJS / Express / Fastify
Ваше незнание архитектуры фреймворка очевидно. Вы обвиняете NestJS в плохой производительности, не зная того, что NestJS предоставляет
FastifyAdapter, позволяющий заменить Express на движок, который в 4.5 раза быстрее по бенчмаркам. И медленный тут именно Express, а не NestJS, обратите внимание. Миграция требует изменения 3 строк кода без потери функционала DI и модульности.3. MongoDB vs PostgreSQL
Мы специально выбрали именно MongoDB, потому что у нас часто меняются схемы данных, быстро добавляется новый функционал, убирается старый. Нам проще делать миграции схемы данных с MongoDB, и она отлично подходит под наш сценарий.
У нас почти все операции это простые чтения по ID или простым фильтрам, у нас нет сложных JOIN'ов и требований ACID к транзакциям. Нам нет смысла использовать PostgreSQL на данном этапе проекта.
А ещё MongoDB гораздо проще и эффективнее масштабируется горизонтально.
Опять, какой-то эмоциональный наброс без аргументов.
4. Docker
Исследования IBM демонстрируют, что накладные расходы контейнеризации в Linux составляют <2%. Docker не эмулирует железо — он использует cgroups и namespaces ядра. В эту же тему можно почитать здесь. Для продакшн проектов изоляция зависимостей и воспроизводимость окружения критичнее гипотетических 1-2% потерь.
Если вы заявляете про "20-30% потерь" — это или намеренная дезинформация, или непонимание сути технологии. Перестаньте распространять ваше заблуждение.
Очень рад, что у меня появился первый хейтер!
Ваши утверждения либо основаны на устаревших данных, либо это просто рандомные набросы без аргументов.
Разберем по пунктам:
1. Docker
Исследования IBM демонстрируют, что накладные расходы контейнеризации в Linux составляют <2%. Docker не эмулирует железо — он использует cgroups и namespaces ядра. В эту же тему можно почитать здесь. Для продакшн проектов изоляция зависимостей и воспроизводимость окружения критичнее гипотетических 1-2% потерь.
Если вы заявляете про "20-30% потерь" — это или намеренная дезинформация, или непонимание сути технологии. Перестаньте распространять ваше заблуждение.
2. NestJS / Fastify
Ваше незнание архитектуры фреймворка очевидно. Вы обвиняете NestJS в плохой производительности, не зная того, что NestJS предоставляет
FastifyAdapter, позволяющий заменить Express на движок, который в 4.5 раза быстрее по бенчмаркам. Миграция требует изменения 3 строк кода без потери функционала DI и модульности.3. MongoDB vs PostgreSQL
Мы специально выбрали именно MongoDB, потому что у нас часто меняются схемы данных, быстро добавляется новый функционал, убирается старый. Нам проще делать миграции схемы данных с MongoDB, и она отлично подходит под наш сценарий.
У нас почти все операции это простые чтения по ID или простым фильтрам, у нас нет сложных JOIN'ов и требований ACID к транзакциям. Нам нет смысла использовать PostgreSQL на данном этапе проекта.
А ещё MongoDB гораздо проще и эффективнее масштабируется горизонтально.
Опять, какой-то эмоциональный наброс без аргументов.
4. NGINX
Спасибо большое за совет, но у нас он и так используется в качестве Reverse Proxy. Тут пустая болтовня.
5. SSR
SSR мы в течении пары дней после запуска заменили на SSG. SSR во время релиза там остался по ошибке - я не проверил эту часть перед запуском, а разработчики, которые этим занимались тоже упустили это. Конечно, SSR тут это очень плохо и бессмысленно.
Резюмируя: выглядит так, что вы всю жизнь сидите на одном стеке с любимым потсгресом, а свои проекты деплоите по FTP (попробуйте CI/CD, не знаю слышали о таком или нет).
Обвинять меня в обмане вы, конечно же, не имеете ни прав, ни оснований. Мои данные открытые и публичные.
По вопросам веры - в церковь.
Ваш заминусованный профиль только подтверждает мои слова, что это просто рандомные набросы, чтобы потешить своё эго. Сегодня не выйдет. По фактам вы уничтожены. Приходите завтра.
Нет, в целом конечно не первый.
Но из таких, которые получают реально существенный трафик за несколько дней и где надо думать про оптимизации - первый.
Спасибо! Учтём.
Спасибо за комментарий! Во второй части будет ещё интереснее :)
Брали классические x86 root сервера. Монга пока на том же хосте, да.
Спасибо за комментарий!
На этапе первого запуска мы сознательно выбрали простой и предсказуемый сетап — тот, в котором всё работает именно так, как мы ожидаем, и стоит заранее известную сумму. При этом да, у нас есть единая точка отказа, это не очень надёжно.
Сейчас уже начинаем рассматривать более гибкие решения, похожие на то, что вы описали.
Наш характер нагрузки хорошо под это подходит: чаще всего в приложении онлайн до 500 пользователей, но бывают резкие всплески — когда за несколько секунд заходят 10–15 тысяч человек.
Автоскейлинг и распределение по нескольким зонам доступности действительно сделают систему надёжнее. Возможно, это окажется и дешевле при нашей текущей нагрузке — хотя многое будет зависеть от её характера. Сейчас пики редкие и кратковременные, но уже в следующем футбольном сезоне (через 3 месяца) мы ожидаем изменения.
Мы планируем серьёзные продуктовые доработки и хотим, чтобы пользователи заходили не только во время матчей, но и между ними. Это может привести к росту постоянного онлайна и изменению профиля нагрузки — соответственно, изменятся и расходы.
Я думаю, что ваш подход на текущей нагрузке точно будет надежнее и выгоднее. Но в будущем нужно будет посчитать.
Острой необходимости в SSR нет, и на текущий момент мы уже полностью перешли на SSG, про это будет подробнее во второй части статьи. Вы правы, на счёт того, что фронтенд сервер вообще не нужен, планируем убирать его.
Не соглашусь с тем выводом, который вы делаете.
Соглашусь с тем, что несколько миллионов DAU можно держать на таком железе. Поэтому мы его и брали, чтобы был запас. И тут я хотел скорее подчеркнуть именно то, что за такие небольшие деньги можно получить такие мощности, которые позволят держать несколько миллионов DAU.
Мы понимали, что вопрос именно в оптимизациях и корректной конфигурации.
На самом деле, сейчас у нас всё очень комфортно по нагрузке: даже в пиковые моменты фронтенд сервер загружен не больше чем на 4%, а бэкенд — максимум на 18%. Это ситуации когда большой единомоментный трафик, больше чем 15 тысяч пользователей заходят за несколько секунд. А в обычных ситуациях нагрузка на фронт в районе 1%, на бэк - 3%.
Поэтому, не думаю, что есть какая-то проблема в стеке JS + MongoDB.
Запас по ресурсам у нас сейчас приличный, и видно, что есть ещё куда оптимизировать, например, внедрить кэширование уже на уровне бэкенда (пока его у нас нет). Так что вопрос скорее не в стеке, а в том, как его использовать и насколько грамотно всё настроено.
Соглашусь, 100 000 уников за 3 дня это не много. Но, ключевой фактор тут - это характер нагрузки. Есть ярковыраженные вспелски, когда за несколько секунд 10-15 тысяч пользователей одновременно заходят в приложение.
Мы изначально брали сервера с запасом, потому что не было чёткого понимания, сколько реально придёт пользователей. По прогнозам, максимум могло быть до миллиона за три дня, минимум — тысяч 50. В итоге, вышло что-то среднее, но инфраструктуру закладывали именно с прицелом на максимальные значения, чтобы не получить аврал в случае удачного запуска.
VPS за 5 долларов у ноунейм-провайдера, как правило, сильно ограничена по ресурсам. Если вдруг в течение пары секунд в приложение зайдёт 20 тысяч человек — такой сервер просто ляжет, особенно если это не статичный сайт, а динамическое приложение с авторизацией, API и базой данных. Тут вы, мне кажется, немного не учитываете реальные ограничения дешёвых VPS.
Ну и плюс — мы специально брали инфраструктуру с запасом, чтобы потом не возвращаться к этому вопросу через месяц и не заниматься экстренным переносом. Это даёт возможность спокойно развивать продукт, не боясь внезапных всплесков трафика. При этом соглашусь, мы бы могли обойтись серверами не за 200 $, а скажем за 50 $, реалистично. Но разница между этими цифрами не такая уж существенная.
Да, буду про это писать.
Есть что рассказать по этой теме.
Спасибо за ваш интерес!
Основной конкурент это spravochnick.ru и znanija.com
Их бизнес-модель работает потому что она у них есть :)
У них она немного разная. Справочник в конечном итоге зарабатывает на комиссии за заказные работы для студентов. Знания продают подписку за безлимитное пользование сервисом.
Они определённо зарабатывают, но мы и не думали пытаться забрать их аудиторию применив их бизнес-модели. Мне кажется справочник зарабатывает гораздо больше, чем знания.
Мы в целом мало думали про бизнес-модель. А то, что у нас было в голове - было про монетизацию не через заказные работы для студентов, а каким-то другим образом.
Спасибо за фидбек!
Спасибо, очень интересно было почитать ваши комментарии.
Подумаем в этом направлении.
Спасибо за такой вдумчивый и глубокий комментарий!
Забрасывать не планируем, это точно. Тут уже даже спортивный интерес включается - просто посмотреть как во времени будет развиваться ситуация с органическим трафиком.
И да, вы очень правильно подметили, что зарабатывать на своих продуктах это задача со звёздочкой. Лично я убеждён, что успешный стартап - это вопрос количества попыток. Конечно, нужно учиться на своём и чужом опыте, но всё равно - даже если учесть все ошибки - в следующий раз, скорее всего, возникнут новые.
Не ошибается тот, кто ничего не делает.
Да, касаемо бедных студентов в точку. Мы так и думали. Поэтому наши идеи по монетизации и строились на том, чтобы их сводить с заинтересованными организациями. Такие организации точно есть.
Касаемо корпораций - мы смотрим сейчас в сегмент корпоративного обучения, в формате микрообучения. Кто знает, может быть с этим что-то получится.
Ваша идея интересная. Вы затронули тему того, что нет общепринятой методологии изучения. Согласен с вами. Мне кажется, тут главный вопрос в том, чтобы изобрести именно методологию. Программный продукт, на мой взгляд, здесь второстепенен, он сделается под методологию легко.
Изобрести универсальную методологию по изучению языков самостоятельно, которая подходила бы всем - это не просто. Возможно поэтому её и нет.
Ведь учить язык это более комплексное занятие, чем учить ответы на вопросы, к примеру.
Будет круто, если у вас получится! Подумаю ещё над вашими тезисами.
Молодец! Ты не такой как все!
Большое спасибо! Будут.
Буду писать про техническую составляющую и про построение команды