Как вы считаете, если у вас смартфон с самым производительным процессором на рынке, но вы не можете нажать на кнопку на экране пока этот экран открывается, и вам нужно ждать конца анимации, этот смартфон можно назвать самым производительным?
Телефоны на андроид, даже со слабым процессором, позволяют нажать на кнопку сразу, как только её видно, не дожидаясь конца анимации (которая там тоже есть, не лукавьте).
У меня товарищ с Mi A1 на 636 драконе нажимал на иконку приложения и потом сразу назад, потом снова на другую иконку и снова назад, делал это быстро, анимация даже прерывалась, но приложения открывались (это вам не нужно каждый раз, но он восхищался как это быстро работает). На айфоне я не могу в настройках, когда выбираю пункт ("основные", например) не могу сразу выбрать подпункт даже если я его вижу или точно знаю где на экране он находится.
хочет надёжности, и за этим уходит от сложности. Но сложность в индустрии появилась ради надёжности
Мне кажется вы немного путаете понятия сложности самой системы (которая с одной стороны как раз вредит надежности, так как чем больше механизмов в устройстве или кода в программе — тем потенциально больше проблем можем с этим возникнуть) и сложности при разработке и поддержке этой системы. Да, сейчас школьник может написать программу для смартфона по распознавания текста на фотографии, не умея даже собственного сервера и никакого опыта в машинном обучении, просто повторив туториал по какому-нибудь TensorFlow.
Сложнее всего ведь создавать простые вещи, которые будут работать и быть надежными, потому что они простые.
Go или Rust или другие языки связывают руки программисту, не давая выстрелить в ногу, в то время как на C/С++ вы вольны это сделать. Но попробуйте сейчас написать json-парсер или http-сервер на C. Вам точно пригодится высшее образование. На go это сделать проще и благодаря этому мы можем строить бóльшие и более сложные системы, которые будут кроме этого надёжны и просты в поддержке.
Кажется, будто из-за этого профессионала с годами стажа может заменить выпускник университета, но это не совсем так. У профессионала есть опыт, просто раньше это опыт, условно — искать глазами в коде возможные разыменования nil-ов (зачем эти ваши новомодные статические анализаторы, ими только новички пользуются, а я ведь профессионал!), а теперь это опыт другого характера — пусть даже написать на вечер сервис, на который раньше была нужна команда программистов и месяцы работы.
Тоже начинал с Financisto, но когда понадобилась синхронизация тоже стал искать что получше и нашел BudgetBakers: Wallet, это было лучшее что нашел на тот момент.
Сейчас пользуюсь iOS, поэтому важно то, что есть версия под iOS и web (хоть функционал и урезан) с синхронизацией и всё это в бесплатном тарифном плане (а платный не сильно дорогой). Если перейду на андроид, обещаю попробовать ваше приложение.
Вы конечно всё хорошо и правильно написали. Но это справедливо только для тех, кто пользуется IDEA. Но что же делать всем остальным?
И немного отвечая на комментарийhabradante: в IDEA, если я не ошибаюсь, если писать a.Name, он будет подсказывать и .lpszName в том числе (если не в первую очередь)
Да, можно и так сделать. Главное чтобы много не копилось таких "мелких фич, которые потом будут перекрыты одной большой", я думаю будет мешать. Но в общем ваш вариант тоже неплох
По поводу объективной/субъективной критики согласен, но не полностью. Поясню.
Могут быть логичные и объективные причины внести какие-то изменения в проект, которые не будут сочетаться с виденьем автора, его долгосрочными планами по поводу проекта и т.д. Например вы просите внедрить локальную фичу для какого-то редкого случая, а автор в это время планирует сделать какое-то глобальное изменение, которые поможет и в вашем случае и в других.
Но, в итоге, конечно больше всего влияет адекватность. Если и автор и комментатор адекватны, они найдут общее решение. В данной ситуации комментатор был, судя по всему, не очень адекватен.
Я считаю что разработчик вправе придерживаться своей точки зрения по поводу своего проекта. Он не обязан доказывать свою правоту. Он разработал что-то и выложил в открытый доступ. Вы не обязаны этим пользоваться. А если уже пользуетесь – будьте благодарны, предлагайте изменения, поддерживайте проект, считаясь с мнением автора. А для несогласных
Похожий подход используется в YouTube API кстати. Но видимо Facebook было этого мало.
Вообще, если смотреть на GraphQL и на такой способ определения необходимых полей, то создаётся впечатление, что это – урезанная версия GraphQL, ну или адаптация его под REST. Возможно что только у меня.
Ну и этот вариант не умеет в именованные запросы, параметры, типизацию и другое что умеет GraphQL
В таком случае да, согласен, такой синтаксис был бы удобен. Можно начинать писать предложение, не мы первые кому не всё нравится в стандартной реализации.
Лимиты и пагинация (видимо имеется в виду указание offset-а) могут быть также реализованы через аргументы и ограничены на backend-е до нужных значений (чтобы нельзя было запросить сразу миллион документов). Ну и документ по ссылке из сообщения VlastV
Можно создать endpoint user и при запросе без аргументов отдавать всех пользователей (не больше определенного количества конечно), при указании id выдавать конкретного пользователя, при указании списка из нескольких id или ограничений (from..to) пользователей с соответствующими id.
Можно сделать один endpoint, через него получать данные, через него же и устанавливать (аргумент set, например, будет устанавливать новое значение для поля). Это плохое решение, лучше разделять получение данных и установку (и запросы GET/POST), но технически можно сделать даже одним endpoint-ом.
То, что я не представляю как должно работать – это только мои мысли, я думал о подобном ещё когда не знал ничего о GraphQL. Можно делать и без этого, сразу получая данные в resolver-е, как и описано в статье.
Остальное – библиотека для работы с GraphQL, алгоритм проверки вложенности – да, конечно это усложнение проекта, но если вы захотите подобное реализовать для REST архитектуры, вам тоже придётся усложнять ваш проект.
По поводу канонического REST – возможно действительно нигде не описано что должен возвращаться только этот объект. И я, создавая REST backend-ы, возвращал помимо полей объекта, хранящихся в БД, другие поля, вычисленные или полученные из других объектов.
Но наверное в любом руководстве к REST в качестве примера будет один возвращаемый объект, а не вложенные.
Возможно я неправ по поводу этого пункта, в любом случае это мало относится к GraphQL.
Парсинг можно отдать внешней библиотеке.
Проверять вложенность можно также доверить библиотеке или написать middleware который будет этим заниматься.
Работать с БД можно используя модели, отправляя запросы не напрямую с resolver-ов, а, как это показано в примере, делать что-то вроде
Posts.find({ id: args.id });
А модель Posts уже знает какой запрос нужно отправить и т.д.
В идеале даже не запрашивать данные сразу, а возвращать некие promises, которые будут оптимизированы и выполнены с минимальной нагрузкой уже после работы resolver-ов (т.е. не отправлять 10 запросов, а отдать 10 промисов и потом, перед отправкой, объединить их в один запрос, если это оказалось возможным). Но это только мои мысли, я не знаю систем, которые сейчас работают подобным образом.
Я писал про REST имея в виду каноничный REST, который в ответе на запрос объекта возвращает только объект и всё, без вложенных объектов. Разработчики backend, конечно, могут отправить данные, но, насколько я понимаю, REST задумывался именно так. Возможно конечно что я неправ.
Лично мне GraphQL нравится скорее за возможность указать какие поля в ответе нужны клиенту.
В реальном приложении я бы использовал ограничение количества документов и уровня вложенности: не более 2-3 уровней, я считаю хватит для большинства приложений, тем более если раньше вы работали с REST API, в котором уровень вложенности зачастую только один.
В этом и прелесть GraphQL что можно вытащить всё необходимое одним запросом.
Да, где-то это будет уязвимостью, и методы защиты ещё не разработаны. Но я уверен, что вместе с распространением этой технологии сообщество (включая компании) найдут решение этой проблемы.
Да, вы правы, с GraphQL действительно вытащить всю базу проще, чем используя, например, REST, где пришлось бы делать по запросу на категорию, потом по запросу на каждый товар и т.д.
Но и используя REST возможно это сделать. Как решается эта проблема? Самое простое решение – ограничивать число запросов с одного IP за какое-то время.
В случае GraphQL такое сделать сложнее, но всё же возможно: указывать максимальный limit для товаров и т.д. Я думаю что с распространением GraphQL будут разработаны методы защиты от таких атак.
Также, помня что эта технология была разработана Facebook, можно посмотреть как они борются с подобным (и борются ли вообще?)
Верно ли я понимаю, что речь идёт именно о некоем аналоге SQL?
Нет, скорее речь идёт о замене/дополнению к REST API – своеобразной форме взаимодействия (язык общения, если угодно) между клиентом и сервером.
Что такое «полностью статическое клиентское React-приложение»?
Знаю React поверхностно, так что могу быть неправ. Скорее всего автор имеет ввиду создание статических страниц (наподобие GitHub Gist), причём Gatsby собирает их на компьютере разработчика, делая запросы к БД при помощи GraphQL, собирая всё так, что при работе сайта БД уже не требуется, так как все необходимые данные были получены при сборке и были интегрированы в саму страницу.
Существует ли какая-нибудь готовая теория (или фрагмент теории) запросов описываемого вида?
Не понял вопроса. Теория – сама эта статья, есть примеры кода, есть ссылки на учебники, руководства. Или вы имеете ввиду что-то другое?
взглянуть на архитектуру базы данных
GraphQL не привязан к структуре базы: в базе данных может не существовать полей author или commentsCount – согласно примеру, посты могут храниться в postgres, поле commentsCount будет каждый раз подсчитываться:
SELECT COUNT(*) FROM comments WHERE post_id=$1
Ещё какие-то вещи могут хранится в Redis и т.д., а GraphQL обеспечивает единый механизм доступа к этим данным и необходимую вложенность
Как вы считаете, если у вас смартфон с самым производительным процессором на рынке, но вы не можете нажать на кнопку на экране пока этот экран открывается, и вам нужно ждать конца анимации, этот смартфон можно назвать самым производительным?
Телефоны на андроид, даже со слабым процессором, позволяют нажать на кнопку сразу, как только её видно, не дожидаясь конца анимации (которая там тоже есть, не лукавьте).
У меня товарищ с Mi A1 на 636 драконе нажимал на иконку приложения и потом сразу назад, потом снова на другую иконку и снова назад, делал это быстро, анимация даже прерывалась, но приложения открывались (это вам не нужно каждый раз, но он восхищался как это быстро работает). На айфоне я не могу в настройках, когда выбираю пункт ("основные", например) не могу сразу выбрать подпункт даже если я его вижу или точно знаю где на экране он находится.
Мне кажется вы немного путаете понятия сложности самой системы (которая с одной стороны как раз вредит надежности, так как чем больше механизмов в устройстве или кода в программе — тем потенциально больше проблем можем с этим возникнуть) и сложности при разработке и поддержке этой системы. Да, сейчас школьник может написать программу для смартфона по распознавания текста на фотографии, не умея даже собственного сервера и никакого опыта в машинном обучении, просто повторив туториал по какому-нибудь TensorFlow.
Сложнее всего ведь создавать простые вещи, которые будут работать и быть надежными, потому что они простые.
Go или Rust или другие языки связывают руки программисту, не давая выстрелить в ногу, в то время как на C/С++ вы вольны это сделать. Но попробуйте сейчас написать json-парсер или http-сервер на C. Вам точно пригодится высшее образование. На go это сделать проще и благодаря этому мы можем строить бóльшие и более сложные системы, которые будут кроме этого надёжны и просты в поддержке.
Кажется, будто из-за этого профессионала с годами стажа может заменить выпускник университета, но это не совсем так. У профессионала есть опыт, просто раньше это опыт, условно — искать глазами в коде возможные разыменования nil-ов (зачем эти ваши новомодные статические анализаторы, ими только новички пользуются, а я ведь профессионал!), а теперь это опыт другого характера — пусть даже написать на вечер сервис, на который раньше была нужна команда программистов и месяцы работы.
Тоже начинал с Financisto, но когда понадобилась синхронизация тоже стал искать что получше и нашел BudgetBakers: Wallet, это было лучшее что нашел на тот момент.
Сейчас пользуюсь iOS, поэтому важно то, что есть версия под iOS и web (хоть функционал и урезан) с синхронизацией и всё это в бесплатном тарифном плане (а платный не сильно дорогой). Если перейду на андроид, обещаю попробовать ваше приложение.
Вы конечно всё хорошо и правильно написали. Но это справедливо только для тех, кто пользуется IDEA. Но что же делать всем остальным?
И немного отвечая на комментарий habradante: в IDEA, если я не ошибаюсь, если писать
a.Name, он будет подсказывать и.lpszNameв том числе (если не в первую очередь)вероятно речь про проброс портов
Да, можно и так сделать. Главное чтобы много не копилось таких "мелких фич, которые потом будут перекрыты одной большой", я думаю будет мешать. Но в общем ваш вариант тоже неплох
По поводу объективной/субъективной критики согласен, но не полностью. Поясню.
Могут быть логичные и объективные причины внести какие-то изменения в проект, которые не будут сочетаться с виденьем автора, его долгосрочными планами по поводу проекта и т.д. Например вы просите внедрить локальную фичу для какого-то редкого случая, а автор в это время планирует сделать какое-то глобальное изменение, которые поможет и в вашем случае и в других.
Но, в итоге, конечно больше всего влияет адекватность. Если и автор и комментатор адекватны, они найдут общее решение. В данной ситуации комментатор был, судя по всему, не очень адекватен.
Я считаю что разработчик вправе придерживаться своей точки зрения по поводу своего проекта. Он не обязан доказывать свою правоту. Он разработал что-то и выложил в открытый доступ. Вы не обязаны этим пользоваться. А если уже пользуетесь – будьте благодарны, предлагайте изменения, поддерживайте проект, считаясь с мнением автора. А для несогласных
Похожий подход используется в YouTube API кстати. Но видимо Facebook было этого мало.
Вообще, если смотреть на GraphQL и на такой способ определения необходимых полей, то создаётся впечатление, что это – урезанная версия GraphQL, ну или адаптация его под REST. Возможно что только у меня.
Ну и этот вариант не умеет в именованные запросы, параметры, типизацию и другое что умеет GraphQL
В таком случае да, согласен, такой синтаксис был бы удобен. Можно начинать писать предложение, не мы первые кому не всё нравится в стандартной реализации.
Я бы всё-таки разделял получение данных и изменение: получать GET запросом, менять POST запросом. Так, мне кажется, безопаснее.
Отвечаю с точки зрения GraphQL, а не конкретной библиотеки
Эта проблема однозначно решаема. Либо расширением спецификации, чтобы было возможно писать
примерно как это реализовано в mongodb
либо даже без изменения спецификации:
Лимиты и пагинация (видимо имеется в виду указание offset-а) могут быть также реализованы через аргументы и ограничены на backend-е до нужных значений (чтобы нельзя было запросить сразу миллион документов). Ну и документ по ссылке из сообщения VlastV
Также VlastV дал ссылку, там вроде то, что нужно
Можно создать endpoint
userи при запросе без аргументов отдавать всех пользователей (не больше определенного количества конечно), при указанииidвыдавать конкретного пользователя, при указании списка из несколькихidили ограничений (from..to) пользователей с соответствующимиid.set, например, будет устанавливать новое значение для поля). Это плохое решение, лучше разделять получение данных и установку (и запросы GET/POST), но технически можно сделать даже одним endpoint-ом.Backend будет отдавать только то, что вы его "научите" отдавать.
Frontend будет запрашивать только то, что ему нужно для отображения пользователю.
То, что я не представляю как должно работать – это только мои мысли, я думал о подобном ещё когда не знал ничего о GraphQL. Можно делать и без этого, сразу получая данные в resolver-е, как и описано в статье.
Остальное – библиотека для работы с GraphQL, алгоритм проверки вложенности – да, конечно это усложнение проекта, но если вы захотите подобное реализовать для REST архитектуры, вам тоже придётся усложнять ваш проект.
По поводу канонического REST – возможно действительно нигде не описано что должен возвращаться только этот объект. И я, создавая REST backend-ы, возвращал помимо полей объекта, хранящихся в БД, другие поля, вычисленные или полученные из других объектов.
Но наверное в любом руководстве к REST в качестве примера будет один возвращаемый объект, а не вложенные.
Возможно я неправ по поводу этого пункта, в любом случае это мало относится к GraphQL.
Парсинг можно отдать внешней библиотеке.
Проверять вложенность можно также доверить библиотеке или написать middleware который будет этим заниматься.
Работать с БД можно используя модели, отправляя запросы не напрямую с resolver-ов, а, как это показано в примере, делать что-то вроде
А модель Posts уже знает какой запрос нужно отправить и т.д.
В идеале даже не запрашивать данные сразу, а возвращать некие promises, которые будут оптимизированы и выполнены с минимальной нагрузкой уже после работы resolver-ов (т.е. не отправлять 10 запросов, а отдать 10 промисов и потом, перед отправкой, объединить их в один запрос, если это оказалось возможным). Но это только мои мысли, я не знаю систем, которые сейчас работают подобным образом.
Я писал про REST имея в виду каноничный REST, который в ответе на запрос объекта возвращает только объект и всё, без вложенных объектов. Разработчики backend, конечно, могут отправить данные, но, насколько я понимаю, REST задумывался именно так. Возможно конечно что я неправ.
Лично мне GraphQL нравится скорее за возможность указать какие поля в ответе нужны клиенту.
В реальном приложении я бы использовал ограничение количества документов и уровня вложенности: не более 2-3 уровней, я считаю хватит для большинства приложений, тем более если раньше вы работали с REST API, в котором уровень вложенности зачастую только один.
В этом и прелесть GraphQL что можно вытащить всё необходимое одним запросом.
Да, где-то это будет уязвимостью, и методы защиты ещё не разработаны. Но я уверен, что вместе с распространением этой технологии сообщество (включая компании) найдут решение этой проблемы.
Да, вы правы, с GraphQL действительно вытащить всю базу проще, чем используя, например, REST, где пришлось бы делать по запросу на категорию, потом по запросу на каждый товар и т.д.
Но и используя REST возможно это сделать. Как решается эта проблема? Самое простое решение – ограничивать число запросов с одного IP за какое-то время.
В случае GraphQL такое сделать сложнее, но всё же возможно: указывать максимальный limit для товаров и т.д. Я думаю что с распространением GraphQL будут разработаны методы защиты от таких атак.
Также, помня что эта технология была разработана Facebook, можно посмотреть как они борются с подобным (и борются ли вообще?)
Хороший вопрос.
Решение "в лоб" – ограничить уровень вложенности.
Более сложное – вычислять циклы, как это делает nodejs, когда вы делаете
То есть просто не отдавать посты для автора, для которого посты уже были отданы
Нет, скорее речь идёт о замене/дополнению к REST API – своеобразной форме взаимодействия (язык общения, если угодно) между клиентом и сервером.
Знаю React поверхностно, так что могу быть неправ. Скорее всего автор имеет ввиду создание статических страниц (наподобие GitHub Gist), причём Gatsby собирает их на компьютере разработчика, делая запросы к БД при помощи GraphQL, собирая всё так, что при работе сайта БД уже не требуется, так как все необходимые данные были получены при сборке и были интегрированы в саму страницу.
Не понял вопроса. Теория – сама эта статья, есть примеры кода, есть ссылки на учебники, руководства. Или вы имеете ввиду что-то другое?
GraphQL не привязан к структуре базы: в базе данных может не существовать полей author или commentsCount – согласно примеру, посты могут храниться в postgres, поле commentsCount будет каждый раз подсчитываться:
Ещё какие-то вещи могут хранится в Redis и т.д., а GraphQL обеспечивает единый механизм доступа к этим данным и необходимую вложенность