To block or not to block
1В программировании есть понятия «блокирующих» и «неблокирующих» вызовов. Представим тупой пример: нам нужно выдать страницу для просмотра видео, на которой есть количество просмотров этого видео и количество лайкнувших его.
2Блокирующие решение. Мы берем видео, потом обращаемся к базе данных за количеством просмотров и лайков. Получив их, мы формируем красивую страничку со всей нужной информацией. Если база данных тормозит или легла под нагрузкой – пользователь странички не дождется.
3Неблокирующие решение. Мы берем видео, формируем и показываем страницу целиком. Бразуер затем выполняет вставленный нами на страницу асинхронный вызов к базе данных. При завершении этот вызов вставляет полученные количества в нужные места на странице. Если база тормозит – количества появятся позже, чем видео. Если база легла – ну не будет просто на странице этих чисел. Приемлемая функциональность просмотра видео от этого не пострадает.
4Неопытные предприниматели, как и неопытные программисты, обычно строят бизнес на блокирующих вызовах – «когда клиент согласится…», «когда нам это одобрят…», «когда нам это дадут…» и так далее. А если не согласится, если не одобрят, если не дадут? А если согласятся, но позже? А если дадут – но когда неизвестно? Весь бизнес встал?
5Переход от блокирующего способа к неблокирующему невозможен без того, чтобы выделить «критический путь», который мы всегда сможем выполнить сами доступными ресурсами no matter what. И этот критический путь должен давать приемлемый результат для пользователя.
6Шансы на выживание стартапа кратно увеличиваются, если основатели обладают пониманием и компетенциями, способными обеспечить существование этого самого критического пути. Если выживание стартапа целиком зависит от «дадут – не дадут» – скорее всего, не дадут. Или дадут, но не тогда. Или тогда – но не то. Или то и тогда, но не на тех условиях.
7Воoбще-то, этот «критический путь» и есть то, что является ценностью самого стартапа. Все остальное – это ценность тех, кто дает.
