Полностью с тобой согласен. Плюсик жаль поставить не могу, кармы маловато :)
Почему-то все ребята придерживающиеся такого подхода думают, что:
На фронтенде сидят люди которые вообще ничего могут не кодить и ты им дай ответ на сущность вместе с урлом, а они eager load'ом просто будут тянуть все данные которые ты им выплюнешь. Меняй список полей в объекте, меняй все вообще, там ребята динамически все подгрузят ....
На адекватном серьёзном фронте сейчас тайпскрипт, все строготипизированно. Фронту надо описывать все поля которые им пришли и т/д. То есть провести очень много работы.
Почему бы в таком случае url не описать?
Много кейсов когда нужен именно идентификатор. А вырезать его из строки при необходимости — бред полный.
Опять же соглашусь c тобой, что лучше иметь эндпоинт который даст тебе список всех роутов для актуальных ресурсов. Это самое нормальное решение.
Да, согласен, сам пару раз готовя материалы, казалось бы на совершенно банальные темы — открывал для себя много новых и интересных вещей.
Но по поводу того что статья должна остаться в заметках — Не стоит забывать, писать такие банальные вещи надо регулярно, так как одно дело когда новичок который изучает IT целенаправленно гуглит что-то и находит старый (но все ещё актуальный) материал, а другое дело если ему так в ленте попался прикольный материал (который кстати супер свежий будет в таком кейсе) и он его усвоил.
Материал тут подан как раз просто и понятно, то что нужно для знакомства с Linux и Git.
Книги — не статьи, тут немного другой подход)
Ну и раз на то пошло, в книгах есть главы, есть заголовки маленьких блоков, есть сноски, есть комментарии автора и т/д, так что книга — это тоже не текст сплошняком просто разбитый на абзацы.
Мне кажется, в статью, пусть даже это перевод другой статьи, надо вставлять картинки, делать заголовки абзацев (смысловых частей) и т/д и т/п.
Текст написан сплошной простынёй, читать неудобно, я к примеру даже не стал этого делать из-за того что неудобно.
Теоретически это более правильный подход чем просто хранить конфиги в этом же репозитории с основным проектом.
В какой-то степени это можно считать соблюдением этого пункта, если этот репозиторий не доступен всем, а доступен лишь ограниченному кругу людей которые занимаются деплойментом.
Достаточно много всего увидел в комментах, неплохо, на самом деле очень рад что всё больше и больше народу интересуется данной темой. Будущее определённо за PWA.
Большая часть проблем и сложностей которые описаны выше действительно существуют в «классическом» варианте PWA, но слегка отклонившись от классики, можно спокойно решить большую часть всех этих кейсов. Как к примеру сделано у нас в Mobsted.
Типичные примеры решенных кейсов:
— Server side rendering
— Долговременное поддержание авторизации на иконке
И многое другое.
Можно сказать что это даже не «PWA», а «PWA 2.0»
Кстати занимаемся мы этим уже 4 года, начали ещё до того как сам термин PWA был придуман.
И конкуренцию мы составляем очень даже неплохую (~ 5 млн. уникальных посетителей в месяц в различных бизнес сферах)
В скором времени выкатим версию 3.0, и поток вырастет, настолько, что я надеюсь больше ни у кого больше не возникнет вопроса о конкурентоспособности PWA.
Это тоже самое что отрывать себе ноги и руки перед сном.
Мол, ты же ничего ими делать не собираешься ночью, зачем тебе эти инструменты.
С утра обратно пришьёшь.
И вместо того, чтобы дёргать из десктопа за ручки API, написанного на PHP, в котором всё равно написаны SQL команды
Вы мне кажется очень мало сталкивались с разработкой. Если не говорить о устаревших решениях, то люди используют такие вещи как фреймворки, и чаще всего это open source фреймворк, за которым стоит большая аудитория которая регулярно фиксит в нём дыры и т.д и т.п.
Так вот, в этих фреймворках есть заготовленные базовые модели, которые имеют кучу плюшек вроде методов которые вызываются до исполнения SQL, после исполнения SQL. И к примеру на Ruby on Rails ваш чудесный код можно заменить нижеследующим:
Добавление книги
Установка в поле «книг всего» значения (P.S делать так это бред, количество книг должно считаться всегда вызывая метод подсчёта в нужный момент, ну конечно если у вас в таблице не гуглплекс книг и она будет виснуть каждый раз при подобном обращении, тогда да, целесообразно возможно)
after_update :authors_books_inc
...
def authors_books_inc
self.author.books_total = Book.where(author_id: self.author_id).count
end
И код подобный тому что у вас там написан сам сгенерируется и выполнится, ибо подобные задачи обыденные и разработчики фреймворков давно зашили всё это внутрь, чтоб не пришлось писать много кода постоянно.
Я уже выше писал, но вы попробуйте что нибудь посложнее сделать, чем просто посчитать все книги, количество кода увеличиться в 10-ки раз если делать это на SQL
В принципе аргументы статьи достаточно весомые, но тут есть один момент который можно решить псевдо-распараллелив несколько задач.
Я говорю о том моменте когда приходиться выполнять нудную, тривиальную или просто надоевшую вам работу. А когда что-либо надоедает, то продуктивность падает и в целом скорость выполнения задачи тоже. В таких ситуациях стоит переключаться с задачи на задачу, что бы как то «разбавить обстановку», тем самым вы почувствуете что делаете что-то «новое» и станет проще выполнять задачи.
Вы кажется не совсем понимаете что такое клиентская часть, а что такое серверная часть.
Представим ситуацию в которой необходимо сделать некий сервис по учёту книг к примеру, и реализовать отслеживание этого учёта на IOS, Android, Веб и Дестктоп, вот это всё что я перечислил, является клиентской частью.
В качестве базы данных будет к примеру postgresql или mysql — это уровень данных
И есть так называемый backend который к примеру реализован на PHP фреймворке Laravel в виде REST API.
И вам не нужно будет логику описывать 50 раз в каждом из приложений, вы всю логику опишете на уровне API. И единственное что вы будете делать на стороне клиента (IOS, Android, Веб и Дестктоп) это просто правильный вывод и отображение информации с её предварительным получением из API.
Послали запрос на добавление новой книги к примеру. API обработало это, так как нужно и выдало в том формате в котором запросило соответствующее клиентское приложение.
В этом и вся суть трёхуровневой архитектуры, а то что вы описали выше это двухуровневая.
А если клиенты написаны под несколько платформ, на каждой эти вычисления писать?
Я не говорю делать вычисления на клиенте, я говорю делать дополнительную прослойку на серверной стороне которая будет отделять клиентскую часть от базы данных. В ней и писать все вычисления.
А если кто-то полез руками напрямую в таблицу исправлять ВШГ?
Это не совсем хорошая практика исправлять что-либо подключаясь напрямую к базе данных, для избежания каких-либо проблем используют такие вещи как «seed» к примеру, и с помощью этого инструментария и вносят изменения в БД.
Я и хочу продемонстрировать людям, то что не стоит тратить время на подобные методы углубления в БД. Ибо есть куда более важные вещи которые стоят внимания, и если 1/1000 студентов обучающихся по подобной программе вдруг решат стать спецами в базах данных, то это их право, но основной массе стоит давать то, что сейчас очень востребовано на рынке.
Чтобы при выходе с ВУЗа студент мог сразу устроится на нормальную работу, а не иметь очень большое количество знаний, которые ему скорее всего не пригодятся, и при трудоустройстве практически с нуля обучаться тому что потребуется в работе.
Собственно как вы и сказали:
Во-первых, в реальном мире, подобный подход мне мне ни разу не доводилось видеть ни в одном проекте, за все то время, что я занимаюсь разработкой.
Почему-то все ребята придерживающиеся такого подхода думают, что:
На адекватном серьёзном фронте сейчас тайпскрипт, все строготипизированно. Фронту надо описывать все поля которые им пришли и т/д. То есть провести очень много работы.
Почему бы в таком случае url не описать?
Много кейсов когда нужен именно идентификатор. А вырезать его из строки при необходимости — бред полный.
Опять же соглашусь c тобой, что лучше иметь эндпоинт который даст тебе список всех роутов для актуальных ресурсов. Это самое нормальное решение.
Но по поводу того что статья должна остаться в заметках — Не стоит забывать, писать такие банальные вещи надо регулярно, так как одно дело когда новичок который изучает IT целенаправленно гуглит что-то и находит старый (но все ещё актуальный) материал, а другое дело если ему так в ленте попался прикольный материал (который кстати супер свежий будет в таком кейсе) и он его усвоил.
Материал тут подан как раз просто и понятно, то что нужно для знакомства с Linux и Git.
Ну и раз на то пошло, в книгах есть главы, есть заголовки маленьких блоков, есть сноски, есть комментарии автора и т/д, так что книга — это тоже не текст сплошняком просто разбитый на абзацы.
Текст написан сплошной простынёй, читать неудобно, я к примеру даже не стал этого делать из-за того что неудобно.
В какой-то степени это можно считать соблюдением этого пункта, если этот репозиторий не доступен всем, а доступен лишь ограниченному кругу людей которые занимаются деплойментом.
Большая часть проблем и сложностей которые описаны выше действительно существуют в «классическом» варианте PWA, но слегка отклонившись от классики, можно спокойно решить большую часть всех этих кейсов. Как к примеру сделано у нас в Mobsted.
Типичные примеры решенных кейсов:
— Server side rendering
— Долговременное поддержание авторизации на иконке
И многое другое.
Можно сказать что это даже не «PWA», а «PWA 2.0»
Кстати занимаемся мы этим уже 4 года, начали ещё до того как сам термин PWA был придуман.
И конкуренцию мы составляем очень даже неплохую (~ 5 млн. уникальных посетителей в месяц в различных бизнес сферах)
В скором времени выкатим версию 3.0, и поток вырастет, настолько, что я надеюсь больше ни у кого больше не возникнет вопроса о конкурентоспособности PWA.
Мол, ты же ничего ими делать не собираешься ночью, зачем тебе эти инструменты.
С утра обратно пришьёшь.
Вы мне кажется очень мало сталкивались с разработкой. Если не говорить о устаревших решениях, то люди используют такие вещи как фреймворки, и чаще всего это open source фреймворк, за которым стоит большая аудитория которая регулярно фиксит в нём дыры и т.д и т.п.
Так вот, в этих фреймворках есть заготовленные базовые модели, которые имеют кучу плюшек вроде методов которые вызываются до исполнения SQL, после исполнения SQL. И к примеру на Ruby on Rails ваш чудесный код можно заменить нижеследующим:
Добавление книги
Установка в поле «книг всего» значения (P.S делать так это бред, количество книг должно считаться всегда вызывая метод подсчёта в нужный момент, ну конечно если у вас в таблице не гуглплекс книг и она будет виснуть каждый раз при подобном обращении, тогда да, целесообразно возможно)
И код подобный тому что у вас там написан сам сгенерируется и выполнится, ибо подобные задачи обыденные и разработчики фреймворков давно зашили всё это внутрь, чтоб не пришлось писать много кода постоянно.
Я уже выше писал, но вы попробуйте что нибудь посложнее сделать, чем просто посчитать все книги, количество кода увеличиться в 10-ки раз если делать это на SQL
Я говорю о том моменте когда приходиться выполнять нудную, тривиальную или просто надоевшую вам работу. А когда что-либо надоедает, то продуктивность падает и в целом скорость выполнения задачи тоже. В таких ситуациях стоит переключаться с задачи на задачу, что бы как то «разбавить обстановку», тем самым вы почувствуете что делаете что-то «новое» и станет проще выполнять задачи.
Представим ситуацию в которой необходимо сделать некий сервис по учёту книг к примеру, и реализовать отслеживание этого учёта на IOS, Android, Веб и Дестктоп, вот это всё что я перечислил, является клиентской частью.
В качестве базы данных будет к примеру postgresql или mysql — это уровень данных
И есть так называемый backend который к примеру реализован на PHP фреймворке Laravel в виде REST API.
И вам не нужно будет логику описывать 50 раз в каждом из приложений, вы всю логику опишете на уровне API. И единственное что вы будете делать на стороне клиента (IOS, Android, Веб и Дестктоп) это просто правильный вывод и отображение информации с её предварительным получением из API.
Послали запрос на добавление новой книги к примеру. API обработало это, так как нужно и выдало в том формате в котором запросило соответствующее клиентское приложение.
В этом и вся суть трёхуровневой архитектуры, а то что вы описали выше это двухуровневая.
Я не говорю делать вычисления на клиенте, я говорю делать дополнительную прослойку на серверной стороне которая будет отделять клиентскую часть от базы данных. В ней и писать все вычисления.
Это не совсем хорошая практика исправлять что-либо подключаясь напрямую к базе данных, для избежания каких-либо проблем используют такие вещи как «seed» к примеру, и с помощью этого инструментария и вносят изменения в БД.
Чтобы при выходе с ВУЗа студент мог сразу устроится на нормальную работу, а не иметь очень большое количество знаний, которые ему скорее всего не пригодятся, и при трудоустройстве практически с нуля обучаться тому что потребуется в работе.
Собственно как вы и сказали: