Size: a a a

Software Design/Architecture/Zen

2020 September 29

АГ

Алексей Гевондян... in Software Design/Architecture/Zen
а на чем это все написано, кстати?
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Алексей Гевондян
крч все то же самое, что можно написать на обычном ЯП, только с блекджеком и шлюхами) понятно)
ну типа у тебя база фактов поддерживается автоматически и хранит всю историю операций, т.е. да это с блэкджеком и шлюхами и реактивностью
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Алексей Гевондян
а на чем это все написано, кстати?
ну я видел на хаскеле, пхп, котлине и кложуре)) или ты про бд?
источник

АГ

Алексей Гевондян... in Software Design/Architecture/Zen
т.е. получается это методология такая? так то да, это можно написать на любом языке бек + бд + фронт на реакте каком-нибудь
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
таким триплсторам нужен пролог-like решатель
источник

АГ

Алексей Гевондян... in Software Design/Architecture/Zen
вот да, напомнило тоже пролог
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Алексей Гевондян
т.е. получается это методология такая? так то да, это можно написать на любом языке бек + бд + фронт на реакте каком-нибудь
да, методология
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Алексей Гевондян
т.е. получается это методология такая? так то да, это можно написать на любом языке бек + бд + фронт на реакте каком-нибудь
там на самом деле оч круто получается, если воспользоваться этим прекрасным кложуровским правилом код=данные, данные=код можно творить очень прикольные штуки, вроде поднятия лямбд по тригеру "добавь письмо на мыло пользователя"
источник

АГ

Алексей Гевондян... in Software Design/Architecture/Zen
события, условия, действия, причины, предикаты - смоделировать можно что угодно на любом языке
источник

˸A

˸̧̨ ͅBlack Akula˸̧̨ ... in Software Design/Architecture/Zen
Nikita Fedorov
ну типа у тебя база фактов поддерживается автоматически и хранит всю историю операций, т.е. да это с блэкджеком и шлюхами и реактивностью
Напоминает Пролог
источник

КГ

Константин Грачев... in Software Design/Architecture/Zen
источник

AL

Anton Lakotka in Software Design/Architecture/Zen
только не рекомендую пользоваться продуктом который он рекламирует.
AxonFramework крайне отвратный если пишешь на котлине.
источник

VS

Vlad Sobenko in Software Design/Architecture/Zen
Anton Lakotka
только не рекомендую пользоваться продуктом который он рекламирует.
AxonFramework крайне отвратный если пишешь на котлине.
А чем порекомендуете?
источник

AL

Anton Lakotka in Software Design/Architecture/Zen
ничего из того что мне попадалось на глаза.
но можно собрать своего франкенштейна.

Например из компонентов Vert.x
источник

SM

Sergey Milimko in Software Design/Architecture/Zen
Nikita Fedorov
Что думаете про Self-service BI, http://datafabric.cc/ и Logical DWH, возможно кто-то работает с подобным?
Мы что-то похожее внутри своего продукта строим. Вообще это только начало. Через несколько десятков лет этим будет заниматься ИИ, которому в декларативной форме ты будешь указывать какие данные тебе нужны, а он сам будет искать и анализировать.
источник

S

SM in Software Design/Architecture/Zen
Добрый день мазафакеры )
источник

S

SM in Software Design/Architecture/Zen
Парни. Такой вопрос :) Я не разраб, но проект мой. Реализует джун и столкнулись со следующей проблемой.

Есть основной сайт front+back на сервере "А".
Так же есть медиасерверы "B" и "C" и т.д.... (добавляемые в базе).

Основной backend находится на domain.com/backend/
Медиасерверы на поддоменах вида media01.domain.com/backend/

Сейчас загрузка видео на проект осуществляется следующим образом.
Видео загружается на основной сервер "А", а затем передаётся на заданный логикой бэкенда медиасервер "B" или "C".

Проблему со storage - решили. Видео хранится где нужно.
Но вот проблему с нагрузкой на основной сервер "A", лишь усугубили. Т.к. мало того что он принимает как и раньше, так ещё теперь и отдаёт на медиасерверы такой же объём данных, являясь своего рода гейтвеем на приём/передачу.

Обращение к медиафайлам уже идёт корректно через поддомен, там всё в порядке.

Как грамотно это поправить? Не хранить же данные о приоритетном серваке для загрузки видео на фронте?
источник

(

( in Software Design/Architecture/Zen
SM
Парни. Такой вопрос :) Я не разраб, но проект мой. Реализует джун и столкнулись со следующей проблемой.

Есть основной сайт front+back на сервере "А".
Так же есть медиасерверы "B" и "C" и т.д.... (добавляемые в базе).

Основной backend находится на domain.com/backend/
Медиасерверы на поддоменах вида media01.domain.com/backend/

Сейчас загрузка видео на проект осуществляется следующим образом.
Видео загружается на основной сервер "А", а затем передаётся на заданный логикой бэкенда медиасервер "B" или "C".

Проблему со storage - решили. Видео хранится где нужно.
Но вот проблему с нагрузкой на основной сервер "A", лишь усугубили. Т.к. мало того что он принимает как и раньше, так ещё теперь и отдаёт на медиасерверы такой же объём данных, являясь своего рода гейтвеем на приём/передачу.

Обращение к медиафайлам уже идёт корректно через поддомен, там всё в порядке.

Как грамотно это поправить? Не хранить же данные о приоритетном серваке для загрузки видео на фронте?
сделать запрос на аплоад, который будет отдавать ссылку на медиасервер, а на клиенте доставать эту ссылку и на неё отправлять
источник

S

SM in Software Design/Architecture/Zen
(
сделать запрос на аплоад, который будет отдавать ссылку на медиасервер, а на клиенте доставать эту ссылку и на неё отправлять
Офигеть!!! В рот мне ноги! То что нужно... так долго это искал - пипец... как я про этот канал не знал раньше.
источник

S

SM in Software Design/Architecture/Zen
Спасибо чувак!
источник