Как обезопасить свой бекенд от разработчиков?

Григорий Хримян, проблема с одним разработчиком в том, что если он пишет спагетти-код, то только он в нем и может разобраться. Когда он уходит оказывается, что довольно трудно найти ему замену на дальнейшую поддержку этого спагетти-кода. Тем более за те же деньги, которые платили предыдущему, т.к. порог сложности для нового разработчика многократно возрастает. Начинается текучка с регулярностью в один два месяца. В итоге проект практически останавливается в развитии. Поэтому и желательно внедрять код-ревью. Но имея одного разработчика так увы не получится.

Как обезопасить свой бекенд от разработчиков?

Григорий Хримян, можно зарегистрировать доменное имя на себя. Иметь бекапы. Лишить возможности разработчика увести за собой значительную часть команды. Лишить возможности разработчика обращаться к широкой аудитории проекта.

Проект останется за вами. Максимум может произойти разделение, но в условиях отсутствия возможности обратиться к широкой аудитории узнаваемость отпочковавшегося проекта будет стартовать с около нулевых значений.

Видел примеры, когда отпочковавшийся проект в итоге отбирал значительную аудиторию у исходного. Это обычно происходило потому что исходный проект покидала практически вся команда. Но если уходила незначительная часть, а тем более один, то никакого серьезного конкурента как правило не вырастало.

Как обезопасить свой бекенд от разработчиков?

Григорий Хримян, когда есть прибыль найти покупателя не сложно. Если у проекта есть перспектива, то программист займет ваше место, а вместо вас наймет человека, который будет делать всё тоже самое, что делали вы. Если посмотрите на крупные компании, то владельцем на старте проекта является как правило сам разработчик. Это уже если проект вырос его можно передать другому человеку ибо штат огромен, бренд раскручен, юристы и т.д. что один в поле не воин. Компании проблем создать не сможет, а себе вполне.

Как работает на низком уровне Node.js и Angular?

ewb, ангуляр можете рассматривать как "расширенный html". Если вы хотите линию, вы пишите тег <hr>. Наверное было бы здорово, если бы вы могли таким декларативным способом описывать не только линию, а всё что угодно. Например написав <calendar></calendar> вы получили бы полноценный функциональный календарь. Естественно этот компонент еще необходимо создать или взять готовый. Весь фронтенд собирается как конструктор из набора таких компонентов.

Это можно сделать и на jquery. Но на jquery как правило получается спаггети-код, где бизнес-логика перемешивается вместе с DOM. В итоге бизнес-логику становится сложно тестировать и поддерживать. Angular позволяет спроектировать программу таким образом, чтобы отделить бизнес-логику от работы с DOM за счет двухстороннего связывания шаблона с компонентом.

Да, подключается на стороне клиента. У вас возникло непонимание, потому что код на angular принято писать на языке typescript. Браузеры этот язык не поддерживают и как следствие вы очевидно не можете запустить такую программу напрямую в браузере. Следовательно нужно скомпилировать код на typescript в javascript. Node.js здесь используется как инструмент, чтобы выполнять такое преобразование и на выходе получить готовый билд, который сможет исполняться в браузере. На продакшен вы будете выкатывать эти билды, а для разработки использовать исходники на typescript.

Если всё это пока слишком сложно, можете попробовать начать с vue.js. Идея абсолютно такая же, но избавляет вас от необходимости думать обо всем этом. Вы просто берете знакомый вам javascript и начинаете писать. Порог входа максимально упрощен. Люди осваивают vue также просто, как и jquery.

Как работает на низком уровне Node.js и Angular?

Бенчмарки можно поискать в интернете если интересно. Но вообще, в связке веб-сервер + php принято на каждый запрос поднимать новую копию приложения. Конечно это очевидно должно быть медленнее, чем если один раз поднять приложение в памяти.

Ну и перед бекендами всё равно как правило ставят фронтенд-сервера на nginx. Например для отдачи статики или балансировки нагрузки по бекендам.

Просто рассматривайте вопрос с точки зрения, что всегда, когда вы пишите серверную часть приложения в виде долгоживущего процесса (демона), то всегда http сервер (правильнее сказать работа с сетью) будет являться неотъемлемой частью самого этого приложения. Иначе если приложение не работает с сетью, то вы очевидно не сможете с таким приложением взаимодействовать по сети. Вы пишите полноценное самостоятельное приложение.

На php же вы писали по-сути не приложение, а набор скриптов. Приложением там являлся сам php интерпретатор. Веб-сервер принимал запрос, находил необходимый файл со скриптом в файловой системе и отдавал его интерпретатору на исполнение. Интерпретатор выплевывал результат вывода скрипта, откуда веб-сервер забирал этот вывод, добавлял свои заголовки и отправлял клиенту (браузеру). Но большинство серверных программ пишутся конечно же не так, а в виде самостоятельных долгоживущих процессов (демонов).

Правильное тестирование Javascript?

azShoo, замечательно, что вы ссылаетесь на Роберта Мартина. Вот, что Роберт Мартин считает вы получите в итоге вашего подхода к тестированию:

Mocking the interactions between all classes forces you to create mocks that return other mocks (that might return yet other mocks). You have to mock out all the data pathways in the interaction; and that can be a complex task. This creates two problems.

1. The setup code can get extremely complicated.
   
2. The mocking structure become tightly coupled to implementation details causing many tests to break when those details are modified.
   

The need to mock every class interaction forces an explosion of polymorphic interfaces. In statically typed languages like Java, that means the creation of lots of extra interface classes whose sole purpose is to allow mocking. This is over-abstraction and the dreaded "design damage".

Ссылка на полную статью Роберта Мартина https://8thlight.com/blog/uncle-bob/2014/05/10/Whe...
Ссылка на статью о ddd и тестировании www.taimila.com/blog/ddd-and-testing-strategy

“Mock across architecturally significant boundaries, but not within those boundaries.”

Суть всей нашей беседы.

Правильное тестирование Javascript?

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

Поэтому моя аллегория в корне верна, т.к. с точки зрения автомобилиста автомобиль для него является агрегатом, а колеса/двигатель это его внутренние сущности, которые автомобилист не будет использовать по отдельности. А вот например с точки зрения автослесаря агрегатами уже будут являться двигатель и колеса, а автомобиля может не быть вообще. Это зависит от того, под какой бизнес проектируется доменная модель.

Можете смотреть на агрегат как на модуль. Очень плохая идея попытаться разобрать не разбираемую единицу. Даже если эта единица состоит из нескольких классов.

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

sim3x, бизнес-процесс стоит не из одной операции, а из набора операций. Если какая-то из операций дает сбой, то мы имеем частично завершенный бизнес-процесс. Необходимо либо попробовать выполнить неудачную операцию еще раз либо каким-то образом откатить все уже успешно завершенные операции внутри этого бизнес-процесса, чтобы система пришла в консистентное состояние.

По поводу изоляции и согласованности. Чтобы лучше понимать где эти свойства теряются, давайте сначала посмотрим на выдержку из википедии:

Наконец, ещё одно замечание касается того, что в ходе выполнения транзакции согласованность не требуется. В нашем примере, списание и зачисление будут, скорее всего, двумя разными подоперациями и между их выполнением внутри транзакции будет видно несогласованное состояние системы. Однако не нужно забывать, что при выполнении требования изоляции, никаким другим транзакциям эта несогласованность не будет видна.
Тем самым эта промежуточная несогласованность является скрытой.

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

Можете почитать статью Your Coffee Shop Doesn’t Use Two-Phase Commit за редакцией Мартина Фаулера. Если не согласны со мной и это имя для вас хоть что-то значит.

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

PravdorubMSK, вы не можете передать транзакционно деньги даже из рук в руки. Есть момент, когда деньги уже не ваши, но еще и не вашего получателя. Можете на стол деньги выложить. С которого их заберет получатель. Станет очевиднее.

Поэтому вы не можете сделать транзакционный перевод денежных средств между банками. Это гетерогенные системы. Денежные средства будут списаны со счета отправителя. И вы будете это видеть. Как будете видеть и то, что они отсутствуют на счете получателя какое-то время. Как минимум здесь нарушены свойства Isolation и Consistency из ACID. И это нормально для бизнеса. Если произойдет сбой, то денежные средства вернут на счет отправителя. Но это будет отдельная операция на уровне приложения, а не роллбек на уровне базы данных. Я даже не стану вам объяснять почему у вас не получится подружить SOA и ACID.

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

terrier, я не писал, что в нетфликс используют монго. Я о nosql в целом. Из вашей же статьи

This appetite for more data, is pushing the boundaries of traditional RDBMS systems and forcing companies to research alternative data stores.
...
From customer/subscriber information, to movie metadata, to monitoring stats, it’s all hosted in Cassandra.
In most of our uses, Cassandra is the source of truth database. There are a few legacy datasets in other solutions, but are actively being migrated.

Они всё хранят в кассандре, а что не хранят, то в процессе миграции. Кассандра у них это "the source of truth database". От монго они отказались не потому что это плохое решение, а потому что кассандра проще в конфигурации и требует меньшего вмешательства человека.

MySQL и Oracle, у которых якобы "проблемы с горизонтальным масштабированием"

Нет, не якобы. Почитайте хотя бы статью, на которую вы ссылаетесь.

One team even built a sharded RDBMS cluster, with every node in the cluster being replicated twice. This solution is also very complex to manage. We are currently working to migrate to C* for that application.

Очень смешно.

Смешно, это когда читаешь, что "монго/кассандра/etc заточено под конкретные задачи". И начинают потом выдумывать эти самые мифические задачи. У кого насколько фантазии хватит. Всё что угодно, кроме современных интернет-приложений. Для интернет-приложений у них есть реляционные базы. Всё верно. Концепция РСУБД появилась же раньше, чем сам интернет. Никакой логической ошибки здесь нет. Так что да, MySQL. Ну а Mongo это для чего-то там.

Свои проекты vs Основная работа и как между ними не разорваться?

4ainik, развлекательного характера. В сети не было. Нужно построить распределенное решение. Соответственно join, acid, foreign keys из рсубд перестают работать. Выбирать нужно из nosql решений. Доменная модель приложения должна быть eventual consistency вместо transaction consistency. Это значит, что если пользователь удалил аккаунт, то его сообщения удалятся не прямо сейчас, а чуть позже. Чтобы реализовать eventual consistency доменную модель надо проектировать как event-driven architecture. Чтобы события не терялись их нужно атомарно сохранять вместе с изменившейся сущностью. Значит нужны локальные транзакции. Но в mongo их нет. Значит транзакции надо делать на уровне приложения. Ну и т.д. и т.п. Построить распределенное решение не просто, особенно если делаешь это впервые.

Я не знаю где искать профи единомышленников по распределенным системам. Если не жалко времени можешь посмотреть https://www.youtube.com/watch?v=XgfJgbnGpLU там докладчик рассказывает о том как использовать очереди. В конце ему говорят -Александр, вы теряете сообщения. И Александр потерялся. Стаж 10 лет.

Поэтому найти кого-то с хорошей базой невозможно. Тем более в регионах. Сейчас большинство учит исключительно синтаксис языка. От таких только проблемы. Придет понапишет не тестируемого кода на модном фреймворке и убежит. Тебе потом этот хлам разгребать. Ну и если посмотреть истории всех современных интернет-компаний, никто особо единомышленников не искал. Просто человеку было интересно этим заниматься не ради денег и он этим занимался и потому получался хороший продукт, а не полурабочее говно, которое потом пытаются всеми силами разрекламировать и продать.

Как разобраться с авторизацией в Node.js?

evg_96, ничего на русском толком не выучишь. Потрать время на английский. Посмотри как образуются времена группы simple в активном/пассивном залогах и ищи такие предложения в статьях, которые тебе интересно читать. Переводи все значимые слова и запоминай. Остальные предложение пока игнорируй. Можно начать читать про веб браузеры, интернет, html, js на simple.wikipedia.org там почти весь текст написан используя времена группы simple. Потом посмотри как образуются времена continuous и perfect также в активных/пассивных залогах и ты уже будешь готов медленно, с постоянным подглядыванием в словарь, но тем не менее читать официальные сайты mongo/mongoose/passportjs. КПД будет в разы выше, чем чтение непонятных источников на русском, где может быть так что автор сам не понял и тебе рассказал.

Свои проекты vs Основная работа и как между ними не разорваться?

AnneSmith, слушайте, речь идет об интернет-проектах. Ваш одностраничник это похоже продающий лендинг пейдж как приложение к основному бизнесу. Сам по себе такой одностраничник не будет закрывать какую-либо потребность человека. Но если это не так и ваш одностраничник не является всего лишь рекламой ваших услуг/товаров, то покажите нам ваш проект.

Свои проекты vs Основная работа и как между ними не разорваться?

AnneSmith, чтобы зарабатывать деньги, сначала нужно сделать продукт. Сделать его могут за вас или вы сами. В первом случае нужно много денег, во втором много знаний. Еще можно быстренько сваять полурабочий прототип. Но это пройдет только в той нише где есть вакуум или куча денег, чтобы залить рекламой телик/интернет. Если ни вакуума, ни денег, прототип так и умрет не преодолев долину смерти.

whatever73 без денежных отношений не пройдет и месяца и ваш союз с партнером развалится. Вашему партнеру кодеру будет неинтересно то, что для вас является значимым вроде стратегии маркетинга и изучения рынка. Для него это имеет такое же значение, как для вас пыль. По факту продукта еще нет и с этими знаниями вы будете для него бесполезным человеком. Можете попробовать здесь на тостере. Получите тонну помоев, вроде "Слыш поц, а ты сам то чо можеш кроме разговоров про маркетинг???".

И вообще обратись к истории и посмотри, что все крупные интернет компании в своей точке отчета не изучали никакой рынок или маркетинг. Их основатели просто делали то, что им было интересно. И как правило, если основателей больше одного, то все были разработчиками приносящими пользу здесь и сейчас, а не маркетологи или еще хер знает кто со знанием какой-то там никому не нужной сейчас стратегией.

Свои проекты vs Основная работа и как между ними не разорваться?

whatever73, мне когда 21 год был, то через 6 лет я себя представлял чуть ли не цукербергом. После университета занялся собственным проектом и он не готов до сих пор. Хотя всё время трачу на него. Недооценил уровень необходимых знаний, чтобы одному поднять современный проект. По факту вместо программирования 90% времени читал ддд, тдд, солид, грасп, паттерны, верстку, ангуляры, реакты, вебпаки, симфони, зенды, экспрессы, вебсокеты, линуксы, ноде джеесы, тайпскрипты, монги, майскюели, рефинки дб, гиты и прочее и прочее. Сотни их. Английский учил в конце концов. И никакого своего проекта нет. И миллионов тоже. Проект пережил миграцию с свой костыль на php -> codeigniter -> yii1 -> yii2 -> symfony -> socket.io -> свой костыль на node.js. Менялись и базы данных кучу раз mysql -> postgresql -> mongodb -> rethinkdb -> mongodb. Про javascript на клиенте и говорить не хочу, там менялось всё чуть ли не каждый день. Ты всё еще хочешь попробовать ? :)

Как правильно организовать и создать проект?

Алексей, под командой подразумевается дизайнер, верстальщик и программист на битрикс/prestashop/etc в типичной веб студии на конвейере? Так как уникальное решение под бизнес с глубоким вниканием в бизнес-процессы у аутсорсинговых компаний, которые действительно выделяют команду будет оцениваться минимально в несколько миллионов рублей.

На что лучше перейти на Angular, React, Vue?

Максим Иванов, вполне переносим. Просто нужно было сначала с angularjs 1 мигрировать на 1.5, а потом уже на angular

А Вы встречали гениев-программистов?

HrPro100Neka: посади меня за windows и неизвестный мне текстовый редактор или ide я бы может тоже не справился даже зная решение. Поскольку всё что я делал в windows это играл в игры. Я буду отвлекаться на малознакомое/не удобное для меня рабочее окружение вместо того, чтобы сосредоточиться на решении задания. Вы сами попробуйте сменить свою qwerty клавиатуру на dvorak и даже ваша не особо интеллектуальная работа совсем остановится. Пока ищите букву потеряете мысли о том, что вам необходимо было сделать. Теперь еще раз вспомните и подумайте насколько сложно программисту сесть за чужое окружение.

Структурирование исключений. Что вы указываете в качестве exeption code?

Тимур: вообще вы как программист должны и без клиента реагировать на все ошибки с кодом 500, а клиенту отдавать 500 статус с пояснением, что произошла ошибка, но вы уже в курсе и решаете проблему. Точно также, как системные администраторы должны реагировать на 503 ошибки и делать что-то чтобы база данных и другие сервисы снова заработали. Ну а вообще, всегда есть определенный шаблон, по которому необходимо составлять репорт об ошибке, если пользователь хочет, чтобы её действительно решили. Можете попросить указывать URL и примерную дату выполнения запроса. Этих данных достаточно, чтобы отфильтровать в логе нужную ошибку среди остальных и решить её в срочном порядке вне очереди. Непонятно, зачем еще что-то выдумывать. Если пользователь пишет тикет "памаqi всьо цломалос", то такие тикеты нужно игнорировать и закрывать. Они бесполезны.

Какую платёжную систему выбрать для игры, охватывающую весь мир?

Алексей Елецкий: потом же еще с вебмани надо будет на дебетовую карту выводить. Там вроде еще столько же процентов комиссии надо отдать или около того. Итого 40% комиссии :)