Насколько понял по коду в репозитории при проверке access_token идет обращение к базе для проверки не отозван ли токен и для поиска клиента по sub. При большом количестве клиентов не будет проблем с нагрузкой на БД? Кажется, одно из преимущест JWT как раз было в том чтобы избежать таких проверок.
Хотя первую проверку можно оптимизировать, если вынести в кеш (Redis...) список отозванных токенов.
Ну чтобы тут сравнивать в контексте проблем, хорошо бы иметь опыт использованися обеих технологий. У меня такого нет, поэтому вам виднее) Но судя по тому что вы написали, выглядит довольно интересно.
Если говорить про те проблемы которые описаны в статье, то в нативной разработке например (Android) их не меньше, но они другие. Везде есть проблемы, идеального ничего нет, многое зависит от самих разработчиков, их опыта и желания изучать что-то новое.
FGX не бесплатный, да, а вот FMX входит в поставку среды как второй фреймворк. "Платность" такая же как и в VS. Т.е. есть некоммерческое использование (Community версия) и коммерческое.
Ну т.е. если хочу выпустить свой продукт, на котором буду зарабатывать деньги, то нужно в любом случае покупать их лицензию?
Это не совсем корректно, т.к. flutter бесплатный и там никаких ограничей нет.
Сравнения не корректные, судя по сайту FGX платный, да и много людей со знаниями Delphi или желающих в него инвестировать свое время? Dart в этом плане ничем не лучше, но сам язык простой + синтакс похож на Java, переход не такой сложный.
FMX насколько понимаю тоже не совсем бесплатный, по крайней мере на сайте бесплатно предлагают только попробовать.
Ну и к обоим этим проектам вопросы про зрелость, поддержку, количество успешных проектов. Думаю, если поковырять их то там будет куда больше проблем, чем перечислено в статье.
No. On native targets, Dart’s isolate API can enable multiple threads of execution at any given time. The Dart VM uses multiple processor cores to run those threads concurrently.
И про KAPT все равно не правильно изменили:
Для сравнения, в Kotlin есть довольно быстрый фоновый kapt и его более современная замена KSP. В отличие от build_runner в Dart,с ними приятно работать.
Все кто работал с KAPT знают, что основная его проблема - это скорость, он работает очень медленно, медленее даже чем стандартный java annotation processors, про это много где уже писалось и тд. Так что он никак не быстрый и с ним не очень приятно работать, собственно по этой (и не только) причине появился KSP. Зачем это было писать в статье, если вы не работали с этим? Тем более в контексте сравнения с дартом.
Иногда вот думаешь, а зачем я этими проблеми занимаюсь?
Ну да, а под WEB же когда люди пишут на react или других фреймворках у них проблем не бывает, там же все браузеры одинаково работают и CSS у всех стандартно поддерживается и не надо версиями и багами JS парится, там же всегда все работает. И в либах проблем тоже нет, там же без багов сразу пишут и тд.
Везде есть проблемы, почти все всегда можно решить, для этого и нужны разрабы.
Скажу по нашему опыту еще раз, мы делали 2 небольшие админки (REST, авторизация JWT, формы, списки с фильтрацией у группировкой), проблем никаких не было, единственное собирать на CI пришлось заморочиться немного, остальное все работает и сейчас.
Потому что сам SDK действительно интересный, в чем-то уникальный и позволяющий делать крутые, приложения c нестандартным красивым дизайном.
Но все эти сравнения с нативом ни к чему хорошему не приводят, потому что:
они только разжигают новые холивары нейтив VS кроссплатформа, чем еще больше отталкивают людей и привлекают троллей.
решения о переходе принимаются не только на основании технических факторов, но многих других (какая аудитория, сроки, на какие платформы запускать, можно ли быстро нанять новых людей и тд). хотя конечно отстутствие быстрых линтеров для удалений неиспользуемых классов/методов это тоже важно.
Как правило, проекты под нейтив и кроссплатформу - это разные типы проектов и они не конкурируют. Те условно, какой-то большой интернет банкинг с кучей клиентов и сотней разрабов врядли будут делать на кроссплатформе потому что и так достаточно ресурсов держать такую армию разрабов и нативщиков нанять быстрее и проще. В тоже время, какой-то стартап который хочет быстрее запуститься под обе мобильные платформы и где, условно, не хватает ресурсов сразу на все - может попробовать начать сразу на Flutter. Поэтому тут не надо никого агитировать переходить, люди сами придут к тому или иному решению, даже если оно технически не совсем правильное, но с которым у них есть опыт и они его могут развивать.
Для сравнения, в Kotlin есть довольно быстрый фоновый KSP и его более современная замена kapt.
все строго наоборот: сначала был kapt (как реализация стандартного аннотейшн процессора в джаве для котлина, которые работает достаточно медленно), а потом уже появился KSP.
Помимо этого, Flutter не поддерживает сборку проекта под архитектуру x86 для Android.
это конечно очень грустно, но интелы уже давно свои армы под андроид не выпускают, это было очень давно, таким устройствам уже 7+ лет (зенфоны на интеле и др) + там была фишка что заложена эмуляция arm32 либ, тк много кто те времена в приложения не добавлял x86 версии либ, так что может даже и так все заработает.
Если говорить о веб-приложениях, то разработка на Flutter Web будет требовать особый и настолько строгий подход к оптимизации, что заставит переосмыслить ее целесообразность
это все зависит от сценария использованения, для главной страницы магазина - врядли такое подойдет, но для внутренней админки бекенда - вполне, учитывая скорость разработки + функциональность.
Так Android и Jetpack Compose, который упоминается в статье, тоже made by Google и по той же логике точно также могут быть закрыты. Можно, конечно, допустить, что неожиданно Flutter решат закрыть через какое-то время, но объективных причин для этого нет. Сам SDK развивается, количество вакансий и разработчиков растет, есть поддержка Fuchsia (если она когда-нибудь разовьётся во что-нибудь для мобилок).
Вот, например, давайте посмотрим на Dart: когда в него завезли null safety? Правильно, только весной 2021 года, а ведь это базовый механизм статической типизации.
Нет такого общепринятого понятия, как "базовый механизм статической типизации" для null safety. Просто в Kotlin/Swift это появилось уже после того, как вышел Dart. Да и сама фича достаточно сложная для добавления, потому что требует правки всей системы типов, миграции кода библиотек/приложений. Если сравнивать с Kotlin, то в итоге получилось даже лучше, потому что компилятор Dart может использовать информацию о типах и вырезать проверки на null в нативном коде, что повышает производительность и уменьшает размер сборки, а в Kotlin это все остается на границах публичных методов, потому что рантайм ничего не знает об этом. В Dart'e действительно нет многих фишек современных языков, но если смотреть не в моменте, а за период с релиза Flutter то развивается он достаточно бодро и разрабы прислушиваются к коммьюнити. Плюс у Dart'a тут есть возможность насобирать шишек за чужой счет и добавлять фичи более обдуманно. Да, конечно, хочется все и сразу, но развитие есть.
Конечно, прекрасно, что Flutter можно посмотреть в исходниках, как и увидеть, сколько issues сейчас открыто в официальном репозитории: их количество только растёт — это говорит о том, что команда пока не справляется с потоком ошибок. Например, только совсем недавно сделали, чтобы анимации не тормозили на iOS ¯_(ツ)_/¯
Количество isssues не равно количеству ошибок, потому что это могут быть фича реквесты, вопросы по использованию SDK, инфраструктурные проблемы, ошибки в desktop платформах (которые еще не в релизе), да и вообще что угодно. Количество тасок скорее говорит о том, что само сообщество вокруг Flutter большое и растет.
По поводу проблем с анимациями на iOS: такая проблема действительно была, но по статье не понятно, аффектило ли это вас или это просто пример. Когда мы выпускали приложение (которое уже было в сторе на Android) на iOS то таких проблем не было.
Собственный UI, характерный для обеих мобильных платформ
Поведение на разных платформах можно кастомизировать, часть из этого работает уже по умолчанию. В примерах есть приложение, которое на разных платформах выглядит нативно при этом максимально переиспользует общие части. Могут быть и другие варианты как это решить, все зависит от дизайна и требований. Тут действительно можно упрекнуть Flutter в том, что он не может как-то автоматически менять UI на разных платформах, чтобы приложение выглядело нативно, но UI паттерны могут отличаться слишком сильно.
В целом доводы в статье субъективные и эмоциональные, а при таком серьезом решении о миграции всего приложения на другой стек, выглядит как раз необдуманно, но, с другой стороны, дает понимание о подходах в компании к таким вопросам.
Очень странный бечмарк, compose наверное быстр, но больше похоже на что Jetpack Benchmark не умеет работать с Compose и там код не запускался вообще, слишком большая разница.
Flutter (а точнее dart) компилируется в натив на андроиде, в apk попадает *so под разные архитектуры, на стороне джавы написана обертка, которая эти сошки загружает, создает view и на ней уже флаттер рисует через skia.
Compose же на андроиде использует стандартные механизмы отрисовки, а skia используется только для desktop'a, через обертку которую делает JetBrains, но это пока альфа версия.
По поводу Сбертеха. Не скажу за весь, но во многих проектах абсолютно такая же ситуация как описано в статье про «махровый авторитаризм». Новые технологии или идеи высмеиваются, люди которые их предлагают подвергаются натуральной травле в переписках, презентациях, чатах. Это не шутки. Про это тоже у автора было. Понятно, что технологии, ради технологий это не серьезно, особенно учитывая специфику банковских приложений. Но даже объективные факты в виде повышения качества и стабильности приложений не играют никакой роли.
И?
В текущей ситуации, вам кажется что код выше, т.е.:
class BadDouble: Foo<kotlin.Double> {
override fun bar(vararg a: kotlin.Double) {
throw UnsupportedOperationException()
}
}
Должен скомпилироваться в:
public final class BadDouble implements Foo<double>
{
public void bar(double... a)
{
throw ((Throwable)new UnsupportedOperationException("not implemented"));
}
}
Но такая конструкция в текущей версии Java просто не поддерживается, как это уже писал выше.
Какие есть варианты решения проблемы?
1. (как сейчас) выдавать ошибку компиляции
2. не явно преобразовывать Integer[] и вставлять хаки при конвертации между int[] и bar(vararg a: kotlin.Double).
Причем тут дизайн языка, да и vararg вообще, проблема как раз в самой платформе: в Java в принципе нельзя сделать метод с примитивом в качестве generic параметра, что вы и пытаетесь осуществить. Попробуйте переписать пример выше на обычной джаве и скормить там в качестве параметра типа обычный int — на текущей версии Java так сделать нельзя, почему это происходит кидал ссылку в статье про боксинг.
Так и Котлин не может kotlin.Double сконвертить в int для дженериков, поскольку сами дженерики и там и там практически идентичны. Да, он может это не пишет явно в сообщение об ошибке, но тут догадаться и так можно почему это происходит.
Чтобы исправить данный пример можно отметить в самом дженерике тип как kotlin.Double? тогда все будет успешно. Или просто убрать дженерики вообще и написать:
fun bar(vararg a: Double) {
throw UnsupportedOperationException("not implemented")
}
тогда он сгенерит:
public final void bar(double... a) {
throw (Throwable)(new UnsupportedOperationException("not implemented"));
}
Мне кажется достаточно трудно делать какие-то выводы об оптимизациях на уровне JVM в данном случае без отрыва от тестов. Вообще зачем действительно там nop мне трудно сказать, могу лишь предположить, что возможно это как-то связано с дебагом.
Естественно нет, он не будет за вас создавать синхронизацию и прочее. Для большинства случаев это просто не нужно, например если null переменная объявляется внутри метода.
inline все же в scala есть считай из «коробки», а вместо reified type есть TypeTag (если не путаю) с большим функционалом.
Все же разница там есть, если вы говорите про аннотацию inline, то мне кажется текущая версия комплятора скалы не сможет так развернуть лямбды, как это делает котлин, например, для всех функций работы с коллекциями. Если же речь о макросах, то тут у скалы возможности не ограничены, но использовать их сложней. reified type parameters связаны как раз именно с инлайном, поэтому у скалы вероятно тут прямого аналога нет, а TypeTag это вообще вроде как фича из рефлекшена, разве нет?
Вряд ли какая-то статья даст вам конкретный ответ на этот вопрос, пока сами не попробуете.
В сравнение со скалой, вероятно, переходить особого смысла и нет. Хотя если говорить еще про отличия и плюсы, то в статье не упомянули про инлайн функций и reified type parameters. На скале такое сделать значительно трудней. Очень радует маленький рантайм самого языка, особенно это удобно на андроиде, на скале с этим пока не так весело, но работы там вроде как ведутся. Еще в котлине заморочились c примитивами и их массивами, массивы также поддерживают все операции работы с коллекциями (map, find...), причем реализованы они не через ссылочные типы, т.е. боксинга/анбокисинга не будет, если конечно результат потом как-то не явно будет приведен к ссылочному типу, например, объявлен как nullable.
Из минусов:
— плагин для идеи периодически крашится, не критично, но хочется чтобы его довели до уровня;
— странный синтаксис в некоторых местах, например при объявлении свойств и если вдруг захочется добавить аннотацию к конструктору, то придется явно это указать;
Спасибо за статью!
Насколько понял по коду в репозитории при проверке access_token идет обращение к базе для проверки не отозван ли токен и для поиска клиента по sub. При большом количестве клиентов не будет проблем с нагрузкой на БД? Кажется, одно из преимущест JWT как раз было в том чтобы избежать таких проверок.
Хотя первую проверку можно оптимизировать, если вынести в кеш (Redis...) список отозванных токенов.
Ну чтобы тут сравнивать в контексте проблем, хорошо бы иметь опыт использованися обеих технологий. У меня такого нет, поэтому вам виднее) Но судя по тому что вы написали, выглядит довольно интересно.
Если говорить про те проблемы которые описаны в статье, то в нативной разработке например (Android) их не меньше, но они другие. Везде есть проблемы, идеального ничего нет, многое зависит от самих разработчиков, их опыта и желания изучать что-то новое.
Ну т.е. если хочу выпустить свой продукт, на котором буду зарабатывать деньги, то нужно в любом случае покупать их лицензию?
Это не совсем корректно, т.к. flutter бесплатный и там никаких ограничей нет.
Сравнения не корректные, судя по сайту FGX платный, да и много людей со знаниями Delphi или желающих в него инвестировать свое время? Dart в этом плане ничем не лучше, но сам язык простой + синтакс похож на Java, переход не такой сложный.
FMX насколько понимаю тоже не совсем бесплатный, по крайней мере на сайте бесплатно предлагают только попробовать.
Ну и к обоим этим проектам вопросы про зрелость, поддержку, количество успешных проектов. Думаю, если поковырять их то там будет куда больше проблем, чем перечислено в статье.
В оф доках все это есть https://dart.dev/resources/faq#q-is-dart-single-threaded можно было их почитать и не надо придумывать своих терминов и вводить в заблуждение, цитата оттуда:
И про KAPT все равно не правильно изменили:
Все кто работал с KAPT знают, что основная его проблема - это скорость, он работает очень медленно, медленее даже чем стандартный java annotation processors, про это много где уже писалось и тд. Так что он никак не быстрый и с ним не очень приятно работать, собственно по этой (и не только) причине появился KSP. Зачем это было писать в статье, если вы не работали с этим? Тем более в контексте сравнения с дартом.
Ну да, а под WEB же когда люди пишут на react или других фреймворках у них проблем не бывает, там же все браузеры одинаково работают и CSS у всех стандартно поддерживается и не надо версиями и багами JS парится, там же всегда все работает. И в либах проблем тоже нет, там же без багов сразу пишут и тд.
Везде есть проблемы, почти все всегда можно решить, для этого и нужны разрабы.
Другое дело что конкретно под ваш проект этот инструмент не подходит, если говорить про Flutter Web, то это у них как раз описано тут https://docs.flutter.dev/development/platform-integration/web/faq
Можно почитать, попробовать, отказаться.
Скажу по нашему опыту еще раз, мы делали 2 небольшие админки (REST, авторизация JWT, формы, списки с фильтрацией у группировкой), проблем никаких не было, единственное собирать на CI пришлось заморочиться немного, остальное все работает и сейчас.
Очень грустно читать такие статьи.
Потому что сам SDK действительно интересный, в чем-то уникальный и позволяющий делать крутые, приложения c нестандартным красивым дизайном.
Но все эти сравнения с нативом ни к чему хорошему не приводят, потому что:
они только разжигают новые холивары нейтив VS кроссплатформа, чем еще больше отталкивают людей и привлекают троллей.
решения о переходе принимаются не только на основании технических факторов, но многих других (какая аудитория, сроки, на какие платформы запускать, можно ли быстро нанять новых людей и тд). хотя конечно отстутствие быстрых линтеров для удалений неиспользуемых классов/методов это тоже важно.
Как правило, проекты под нейтив и кроссплатформу - это разные типы проектов и они не конкурируют. Те условно, какой-то большой интернет банкинг с кучей клиентов и сотней разрабов врядли будут делать на кроссплатформе потому что и так достаточно ресурсов держать такую армию разрабов и нативщиков нанять быстрее и проще. В тоже время, какой-то стартап который хочет быстрее запуститься под обе мобильные платформы и где, условно, не хватает ресурсов сразу на все - может попробовать начать сразу на Flutter. Поэтому тут не надо никого агитировать переходить, люди сами придут к тому или иному решению, даже если оно технически не совсем правильное, но с которым у них есть опыт и они его могут развивать.
Это не так, см Isolate или вот
все строго наоборот: сначала был kapt (как реализация стандартного аннотейшн процессора в джаве для котлина, которые работает достаточно медленно), а потом уже появился KSP.
это конечно очень грустно, но интелы уже давно свои армы под андроид не выпускают, это было очень давно, таким устройствам уже 7+ лет (зенфоны на интеле и др) + там была фишка что заложена эмуляция arm32 либ, тк много кто те времена в приложения не добавлял x86 версии либ, так что может даже и так все заработает.
это все зависит от сценария использованения, для главной страницы магазина - врядли такое подойдет, но для внутренней админки бекенда - вполне, учитывая скорость разработки + функциональность.
Так Android и Jetpack Compose, который упоминается в статье, тоже made by Google и по той же логике точно также могут быть закрыты. Можно, конечно, допустить, что неожиданно Flutter решат закрыть через какое-то время, но объективных причин для этого нет. Сам SDK развивается, количество вакансий и разработчиков растет, есть поддержка Fuchsia (если она когда-нибудь разовьётся во что-нибудь для мобилок).
Нет такого общепринятого понятия, как "базовый механизм статической типизации" для null safety. Просто в Kotlin/Swift это появилось уже после того, как вышел Dart. Да и сама фича достаточно сложная для добавления, потому что требует правки всей системы типов, миграции кода библиотек/приложений. Если сравнивать с Kotlin, то в итоге получилось даже лучше, потому что компилятор Dart может использовать информацию о типах и вырезать проверки на null в нативном коде, что повышает производительность и уменьшает размер сборки, а в Kotlin это все остается на границах публичных методов, потому что рантайм ничего не знает об этом. В Dart'e действительно нет многих фишек современных языков, но если смотреть не в моменте, а за период с релиза Flutter то развивается он достаточно бодро и разрабы прислушиваются к коммьюнити. Плюс у Dart'a тут есть возможность насобирать шишек за чужой счет и добавлять фичи более обдуманно. Да, конечно, хочется все и сразу, но развитие есть.
Количество isssues не равно количеству ошибок, потому что это могут быть фича реквесты, вопросы по использованию SDK, инфраструктурные проблемы, ошибки в desktop платформах (которые еще не в релизе), да и вообще что угодно. Количество тасок скорее говорит о том, что само сообщество вокруг Flutter большое и растет.
По поводу проблем с анимациями на iOS: такая проблема действительно была, но по статье не понятно, аффектило ли это вас или это просто пример. Когда мы выпускали приложение (которое уже было в сторе на Android) на iOS то таких проблем не было.
Поведение на разных платформах можно кастомизировать, часть из этого работает уже по умолчанию. В примерах есть приложение, которое на разных платформах выглядит нативно при этом максимально переиспользует общие части. Могут быть и другие варианты как это решить, все зависит от дизайна и требований. Тут действительно можно упрекнуть Flutter в том, что он не может как-то автоматически менять UI на разных платформах, чтобы приложение выглядело нативно, но UI паттерны могут отличаться слишком сильно.
В целом доводы в статье субъективные и эмоциональные, а при таком серьезом решении о миграции всего приложения на другой стек, выглядит как раз необдуманно, но, с другой стороны, дает понимание о подходах в компании к таким вопросам.
Очень странный бечмарк, compose наверное быстр, но больше похоже на что Jetpack Benchmark не умеет работать с Compose и там код не запускался вообще, слишком большая разница.
Flutter (а точнее dart) компилируется в натив на андроиде, в apk попадает *so под разные архитектуры, на стороне джавы написана обертка, которая эти сошки загружает, создает view и на ней уже флаттер рисует через skia.
Compose же на андроиде использует стандартные механизмы отрисовки, а skia используется только для desktop'a, через обертку которую делает JetBrains, но это пока альфа версия.
В текущей ситуации, вам кажется что код выше, т.е.:
Должен скомпилироваться в:
Но такая конструкция в текущей версии Java просто не поддерживается, как это уже писал выше.
Какие есть варианты решения проблемы?
1. (как сейчас) выдавать ошибку компиляции
2. не явно преобразовывать Integer[] и вставлять хаки при конвертации между int[] и bar(vararg a: kotlin.Double).
kotlin.Double? — выделил важное жирным
Не знаю откуда вы это взяли вообще.
Читайте внимательней комментарий к таску, там как раз все развернуто описано.
Так и Котлин не может kotlin.Double сконвертить в int для дженериков, поскольку сами дженерики и там и там практически идентичны. Да, он может это не пишет явно в сообщение об ошибке, но тут догадаться и так можно почему это происходит.
Чтобы исправить данный пример можно отметить в самом дженерике тип как kotlin.Double? тогда все будет успешно. Или просто убрать дженерики вообще и написать:
тогда он сгенерит:
что вероятно и хотелось изначально.
Все же разница там есть, если вы говорите про аннотацию inline, то мне кажется текущая версия комплятора скалы не сможет так развернуть лямбды, как это делает котлин, например, для всех функций работы с коллекциями. Если же речь о макросах, то тут у скалы возможности не ограничены, но использовать их сложней. reified type parameters связаны как раз именно с инлайном, поэтому у скалы вероятно тут прямого аналога нет, а TypeTag это вообще вроде как фича из рефлекшена, разве нет?
А так полностью согласен.
В сравнение со скалой, вероятно, переходить особого смысла и нет. Хотя если говорить еще про отличия и плюсы, то в статье не упомянули про инлайн функций и reified type parameters. На скале такое сделать значительно трудней. Очень радует маленький рантайм самого языка, особенно это удобно на андроиде, на скале с этим пока не так весело, но работы там вроде как ведутся. Еще в котлине заморочились c примитивами и их массивами, массивы также поддерживают все операции работы с коллекциями (map, find...), причем реализованы они не через ссылочные типы, т.е. боксинга/анбокисинга не будет, если конечно результат потом как-то не явно будет приведен к ссылочному типу, например, объявлен как nullable.
Из минусов:
— плагин для идеи периодически крашится, не критично, но хочется чтобы его довели до уровня;
— странный синтаксис в некоторых местах, например при объявлении свойств и если вдруг захочется добавить аннотацию к конструктору, то придется явно это указать;