Задать вопрос
  • Комментарии в коде?

    Это не такой простой вопрос, как кажется на первый взгляд.

    1. Правильно пишут выше, что не надо путать комментарии и документацию, технически оформленную в виде комментариев.

    2. Если рассматривать именно комментарии, то они нужны только вот в каких случаях (по моему опыту):

    а) Когда какая-то конвенция дала сбой, но вы все равно решаете не менять ее. Вы в команде договорились, что в данном проекте всегда кладете огнетушитель при входе в помещение в углу слева. Это ваша внутренняя конвенция. Однаком в одном из помещений стены оказываются оранжевого цвета и вы решаете, что на их фоне огнетушитель будет смотреться очень неприметно, и кладете его в нише, которая покрашена в другой цвет. В этом случае надо оставить комментарий, т.к. конвенция нарушена, но это не надо считать ошибкой и в комментарии следует указать причину нарушения.

    б) Когда в силу обстоятельств приходится нарушить ожидаемое для всех поведение. Один из огнетушителей имеет слишком тугой курок. Его следует заменить, однако сроки поставки не позволяют вам сделать это до ближайшего релиза. Поэтому вы кладете рядом с огнетушителем трубу, которую следует использовать как рычаг, насадив на курок, и в комментарии указываете причину такого отклонения от ожидаемого поведения и метод применения workaround'а.

    Все остальные случаи на мой взгляд при ближайшем рассмотрении либо укладываются в эти два, либо являются примером плохой работы.
    Ответ написан
    Комментировать
  • Как лучше реализовать аутентификацию в микросервисной архитектуре?

    Позднова-то наверное, но лучше поздно, чем никогда.

    Два самых важных вопроса:

    1. Каких масштабов проект? По 10-бальной шкале от 0 (интернет магазинчик) до 10 (eBay). Вангую, что не больше, чем 3-4 скорее всего.
    2. Все микросервисы находятся в приватной сети или разбросаны по узлам всемирной паутины? Опять же, скорее всего первое.

    Если мои предположения оказались верны, то:
    1. Нафиг OAuth и прочий геморрой. Вы слишком маленькие ещё для этого, надо все делать как можно проще и конкретней. Гибкость и скорость всегда покупаются человеко-часами, чудес не бывает. Выполните основные требования сусурити (brypt, смертные токены и т.п.) и не более. Напишите что-нибудь сами, простое, понятное, и легко поддерживаемое программистами того уровня, который вы можете нанять. В 50 строк кода влезете.
    2. Поставьте на входе nginx, который на каждый входящий запрос будет спрашивать подзапросом у микросервиса аутентификации: "вот запрос, такие хедеры, такой урл, кто это? его пускать?". И напишите на чем-нибудь типа Go читалку из базы юзеров, которая будет вам за 3 мс давать ответ на такой вопрос (а nginx приклеивать "Вася" к запросу и отправлять дальше или отфутболивать). А если нагрузки большой нет, то можно и медленней, не надо бояться задержки 15 мс на каждый запрос, это вполне оправданная цена за простоту и отсутствие зоопарка языков и технологий.

    Вот тут я накидал очень минималистичный пример: github.com/bitia-ru/examples-microservices-authent...
    Ответ написан
    1 комментарий