Это как no-code его появление не убрало спрос на кадры, а просто увеличило скорость сборки продуктов и повысило удобство

Думаю через пару лет джунам уже будет сложно найти работу

а щас им типа легко?)

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

Здравствуйте всем! я знаю здесь сидят опытные программисты, кто уже много лет занимаются программированием и решают бизнес проблем с помощью IT решений хотел узнать что вы думаете насчет Devin AI? как это коснется рынка IT заранее спасибо за ваш подробный ответ)

Здравствуйте всем! я знаю здесь сидят опытные программисты, кто уже много лет занимаются программированием и решают бизнес проблем с помощью IT решений хотел узнать что вы думаете насчет Devin AI? как это коснется рынка IT заранее спасибо за ваш подробный ответ)

Коллеги а есть ли в симфони какойто общепринятый модуль(или бандл - в терминологии симфы ) для магазинов?

https://sylius.com/

спасибо гляну

там даже админка есть) https://demo.sylius.com/admin/login

Ну с безопасностью у них явно проблемы

Логин и пароль прям на форме логина

Вот я нахожусь на ветки dev [Id статьи]) [название ветки] - [updated_at]: 1) master - 10 2) dev - 3 3) master - 1 Я переключаюсь на master, соответственно запись с id 2 становится неактуальной. Но так как я беру max(updated_at) - это будет 10. Если у мастеровой записи номер 2 будет updated_at меньше 10 то её не зацепит обновлением и она так и останется неактуальной.

забей на оптимизацию запросов, думая что оптимизируешь, ты стреляешь себе в ногу

а синкать данные можно через вебсокет, но ты должен подумать, реально ли но тебе надо + ключем записи должен быть не id а комплексное значение [id + branch] например + ты должен учитывать что статью могут менять с двух устройств и в этом случае тебе надо актуализировать кэш

Почему игрушка дьявола 😂

Ну потому что это отдельная точка отказа, это доработки и на фронте и на сервере. Вот что сокеты могут решить? Только если клиент онлайн и пришло обновление. А что если он был офлайн.

Но я не в контексте поэтому меня не слушай😂

Давай тогда поудаляем сообщения

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

Верно, и это работало до ветвления, так как можно было бы просто по updated at вытянуть

А и не нужно понимать, на каждый чих пользователя делать апи запрос - пользователю будет не в кайф. То что у пользака будет пару мегабайт в файлах крутиться - абсолютно всё равно.

Ну тут вопрос как оно у тебя реализовано

что знчит на каждый чих)

[increment] [article id] [branch name] [article data] 1 uuid1 master {…} 2 uuid1 dev {…} 3 uuid2 master {…} То есть когда я создал ветку dev и в рамках этой ветки решил отредактировать статью uuid1 то при сохранении сервис видит что dev версии статьи нет и тогда он форкает мастер версию и применяет к этой форкнутой версии все изменения. Если дев версия статьи уже существует, то он применяет изменения сразу к ней. Как итог - мастер версия не тронута

Когда ты создаешь дев ветку, надо клонировать статью, иначе получится ты редактируешь статью в дев 10минут в это время кто то в мастере поменял статью и получилась жопка

Вы невнимательно читаете

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

Потому что редактирование статьи это не тема моего вопроса и я все описал в общих чертах. И вообще как мы от «синхронизации кешей» перешли к «версионированию»?

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

Народ, у меня такая проблема. Для оптимизации кол-ва запросов к моему апи я храню копии записей, которые клиент получил из апи в локальном индексируемом хранилище браузера https://learn.javascript.ru/indexeddb В итоге при первом запросе я сканом запрашиваю все данные и сохраняю их в локальную стору, и дальше клиент работает с локальной сторой. Но её нужно обновлять - и тогда я просто беру максимальный updated_at в локальной сторе и запрашиваю по апи все ресурсы которые больше этого updated_at. Это работало до того как я сделал систему веток. Теперь при переключении между ветками могут становиться неактуальными данные где-нибудь посередине локального хранилища, и вот так просто я уже не обновлюсь. Может быть есть какие-нибудь другие способы синхронизации данных?

Очевидные ивенты, например sse и обновление чего изменилось

дада, тут запрос раз в N секунд наоборот создаст нагрузку

Или не создаст. Все зависит от железа и сколько и как часто редачат

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

Ты видимо не знаешь что такое сервер сайд ивенты. Реализация Лонг полингом одна из. А твои изменения получать с сервера подписавшись на события. Зачем запрашивать специально то что изменилось? Когда можно по факту получить.

я знаю что это такое, не понимаю как оно решает мою проблему

Хорошо, то есть твоё решение 1) дополнительно реализовать event sourcing или полностью перевести на event sourcing мои статьи 2) реализовать любой транспорт получения ивентов (long pull, websocket) 3) фронт должен знать про события и хранить id последнего события 3 альтернативный) бек знает последнее запрошенное событие 4) механизм редьюсинга событий что бы клиент не повесился при попытки считать их все

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

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

Источник правды один - сервер. Думай про локальную табличку как про кеш в редисе. Как мы обычно кешируем внешние апи на сервере. Наш код обращается к кешу, а некая прослойка актуализирует этот кеш (по таймеру или по протуханию)

Источник правды один - сервер. Думай про локальную табличку как про кеш в редисе. Как мы обычно кешируем внешние апи на сервере. Наш код обращается к кешу, а некая прослойка актуализирует этот кеш (по таймеру или по протуханию)

Тебе точно нужен этот кеш? Почему стейтменеджера какого реакта не хватает?

потому что при перезагрузки страницы нужно будет заново всё грузить

Это проблема? Как часто страница перезагружается? Если это заточено под мобилу тогда ок )