copal: вы когда-нибудь работали с хранимыми процедурами? Ну мол бородатые дядьки дают вам в базе отдельные функции, и какие-то дергать вам можно, какие-то - нет прав.
На UI вы тоже показываете только то что можно (ибо UX хороший надо), но даже если бы показывали - база данных вам бы не позволила дселать что-то нехорошее.
Тут тоже самое. Сервак - по сути база данных. Клиент - UI. Это очень упрощенная модель, но на сервере обязательно должны быть все проверки аля может чувак чего делать или нет. А на клиенте просто на уровне UI эти проверки обычно.
Антон Штинов: я рекомендую вам вооружиться JWT. Готовые реализации есть и для PHP и для angular.
В токене сразу можно хранить какие-то права пользователя. А далее - ресолверы, которые будут запрещать грузить что не надо, а по поводу ACL - тут разные варианты. Хоть свои директивы, хоть какие-то отдельные модули. Тут конкретики подсказать не могу. Лучше поищите.
Антон Штинов: uiRouter, ресолверы (resolvers). Это решает где-то 70% проблем. Остальные 30% проблем - как решить что показывать а что нет. Ну и все ограничения дублируются на бэкэнде в любом случае.
Как жаль что нельзя ответы минусовать. Вот когда фреймворки начинают жать и слишком уж ограничивать - тогда и нужно от них отказываться. А пока-что - лучше использовать полноценные решения. Но до этого лучше поработать пару лет хотя бы с чем-то готовым.
1) Ну так это означает знать разнообразие функций а не заучивать их, нет? С этим я согласен.
2) Ну то есть у вас насобирались решения стандартных проблем для вашей проблемной области. И область эта не входит в 90%. По сути это правильный подход, может оно еще и в опенсурсе есть?
3) схемки это хорошо, диаграмки и т.д. Визуализация всегда помогает разобраться. Но только визуализировать в этом случае стоит именно бизнес логику, сущности, их взаимодействия. Ну то есть это скорее моделирование предметной области. Архитектура будет формироваться при переносе модели.
Adamos: ну а как иначе если нет готовых решений? Полюбому придется пилить свое. Тут как бы вариантов не особо много.
Алексей Уколов: ну в этом и соль. Тесты, в случае их неудобного написания так же являются первым сигналом того что что-то пошло не так. Через них легко определять что мы нарушили инкапсуляцию и т.д. А с инструментами типа phpspec с кодогенерацией и сахором для моков - все совсем ништяк.
Вообще мне сложно представить себе ситуацию когда тесты отклевают от архитектуры. Тут другой нюанс, что бы архитектура не отвлекала от бизнес логики и т.д. Хорошая архитектура - это архитектура которую легко менять. И тесты в этом плане хорошо помогают.
Хочу заметить что есть профит или нет зависит исключительно от человека. Скажем я никогда не понимал смысла стараться запомнить API. Те функции которые используются чаще всего - их и так запомишь, даже нелогичные варианты коих в PHP хватает.
По пунктам же вопросы к вам:
1) А лично для вас, какой в этом профит? Мне серьезно интересно.
2) Ну то есть делать фасады над конкретными кусками API. Но опять же профит от этого только когда занимаешься однообразными задачами, а стандартные однотипные проблемы и так обернуты в объекты, фасады, сервисы... Symfony и ее экосистема хэндлит 90% стандартных задач.
3) Если в этом мало опыта то и смысла будет мало. Разработка через тестирования для некоторых людей будет гораздо более продуктивным способом. Но повторюсь - не для всех. Людям страдающим отсутствием уверенности в том, что они делают - TDD это хороший способ избавиться от страха. А проектировать все заранее обычно возможно только на самом верхнем уровне архитектуры. Что вы скажите по этому поводу?
Алексей Скобкин: конечно, потому существуют практики типа код ревью и т.д. Ну и даже крутые чуваки иногда допускают "плохие" решения, и осознают о них уже после. Важно понимать что это нормально, и нужно просто пытаться себя обезопасить от них. Например плохое решение на которое завязана вся система - это явно проблема. А если плохие решения изолируются и их можно относительно быстро заменить - тут уже можно проще жить.
webdisigner: не читал, не знаю. Я уж не помню по каким книжкам я учился и подсказать литературу для совсем новичка я точно не смогу...
Максим Анархистов: да, это очень большая проблема. Даже поднимались какие-то инициативы на реддите, обсуждался даже вопрос исключения этих туториалов из поисковой выборки или каким-то образом позволить людям проверять актуальность инфы. Но чето как-то во что это вылилось - увы не знаю.
Проблема еще в том что люди ленивые и редко любят думать головой.
Я к тому что 2 гигабита в секунду это много но не очень. Чисто теоритически решения вроде netmap удобны когда у вас надо обрабатывать потоки в 10+ гигабит в секунду. На таких объемах я бы сразу смотрел на Си и на netmap.
insekt: мм, не могу ответить на этот вопрос пожалуй. 1.5 миллионов пакетов в секунду это довольно много. Я бы на шавем месте исходил из простого, можно быстро написать на Go прототип (в минимальные сроки) и замерять производительность. Если все ок - оставаться с этим. Если нет - смотреть на более низкоуровневые решения.
1.5 миллионов пакетов ... это еще и от размера пакета зависит. Если взять по максимальному MTU (1500) это уже будет порядка 2Gb/s
Go достаточно шустрый язык а в рамках этой задачи мы упираемся в работу с I/O. В Go с его горутинами можно легко и просто распаралелить это дело. На Си же файберы и прочее это сложно, а с потоками мы можем потерять чутка производительности за счет переключения контекста.
