jenya7771, это немного другой подход, но у тебя не очень много выбора по тому что очереди - единственный адекватный паттерн для данного случая. Кроме того чтобы записать объект в кэш ты отправляешь его в очередь с другой стороны которой кто-то слушает сообщения и выполняет те или иные действия
Станислав Меньшов, вот теперь почти прекрасно. Вариант один - управлять этим на сервере по-любому. Клиент в данном случае не при чем абсолютно. Как хранить переводы - вот тут придется много думать по тому что если это все статика то можно использовать ключи и фиксированные словари. Можно их отдельными справочниками в монге сделать, можно вообще в приложении - как будет удобно. А вот если там относительно динамика (писалось про шаблонизирование) то есть два варианта - генерировать на лету или сохранять статику в момент записи. Вопрос как разделять локаль: по заголовку или query - вопрос открытый по тому как для данной задачи действительно не важно. Если даже есть кэширование то его можно настроить на любой набор параметров.
Имхо, клиенту знать переводы не надо - пусть получает их из API. Ну, то что касается взаимодействия с API. А что касается самого клиента (интерфейс) то тут должно быть все в клиенте
Станислав Меньшов, у тебя требования не имеют отношения к решению вопроса. вернее требований нет - это набросок для тз. пока ты полностью не опишешь что это за приложение, какими данными он оперирует (все что нужно знать проданные я выше расписал уже не первый раз), для чего потребовалась интернационализация, как планируется ей управлять и все в таком духе - помочь тебе можно только советом "и так сойдет". А что делаешь ты? Ты возвращаешься к своему укромному уголку бэкэнда. Чтобы решить твою задачу надо знать все существующие части приложения и достаточно глубоко
Станислав Меньшов, ты издеваешься. Ты смотришь со стороны программиста. Пока так будешь делать ты просто бесполезен. Забудь о программировании. Подумай о данных - я тебе это уже какой раз твержу. Что за данные, где они используются, как, какие сущности, как часто обновляются ... А ты начал с написания ТЗ, что не является тем что я написал тебе. Function Analyst из тебя никакой пока что)
Станислав Меньшов, нужна не серверная архитектура, а то какие данные кем и для чего используются. А так же как часто меняются, сколько сущностей, как предполагается управление переводами и вот это вот все. Собери в кучу хотябы вводную информацию, собери требования к системе (функциональные и не функциональные) а потом декомпозируй
Станислав Меньшов, от тебя нет деталей и текущей архитектуры, а потому самый грамотный ответ будет "не важно". К тому же если ты просто backend developer то архитектура взаимодействия вообще не твоя забота
Robur, так получилось что в Питере не так много позиций Solution Architect, не говоря уже о том что очень хочется работать с AWS, а в России из-за законов с этим туговато) В результате вишу в ожидании проектов от таких компаний как Epam, DataArt и т.п. Всем почему-то нужны девопсы (которых, как я считаю, не существует) и системные архитекторы. В общем - редкая рыба на очень небольшом рынке
Gene Hagmt, тогда, пожалуйста, не называй это безопасностью) пусть это будут просто базовые рекомендации для создания хорошего приложения. именно что базовые (anti-ddos к этому точно не относится).
А для именно ИБ используй базовые принципы что я описал выше и думай головой что и для чего ты хочешь сделать и на что это повлияет. А то, знаешь, многим кажется что POST безопаснее GET, а потом приходит осознание что и то и другое все-равно идет по проводам
Gene Hagmt, сколько экспрессии) ИБ начинается с вопросов о том:
- что мы защищаем
- от чего мы защищаем
- где мы защищаем
и из этого уже получается
- как мы защищаем
У AWS есть несколько очень интересных whitepapers, которые можно порекомендовать даже новичкам вроде тебя и безопасность начинается с этих вопросов, продолжается мониторингом (visibility, да-да. а по-хорошему с этого вообще начинается).
Что же сделал ты:
- начитался всякого
- выдернул в отрыве от контекста разные решения от каких-то отдельных случаев
- подумал что собрал какой-то универсальный список решений.
Так не работает, парень. Совсем не работает. Безопасность приложения это огромный комплекс, включающий сбор информации, анализ, множество взвешенных решений и эксперименты. На этот счет написаны сотни книг и существуют огромные талмуды на сотни страниц просто о том "как проверить мой маленький сервер на дыры".
illuzor, по тому что это всегда работает. Если есть пакетные менеджеры, которые с ним не работают - покажите мне, пожалуйста. Я первый брошу в них камень
Иван Шумов
@inoise Куратор тега Amazon Web Services
jazzus, если ты можешь сгенерировать временную ссылку это значит что у тебя по идее вполне хватает доступов и так скачать (я знаю что это разные policy, но мало верю в то что их действительно правильно применяют) и поэтому ты и так действуешь от пользователя или роли у которой есть доступ. Если это так то бери AWS sdk и работай. Если нет, но у тебя все ещё есть желание использовать временную ссылку - file_get_contents никто не отменял
