Итак, это будет мой первый пост в блоге о программировании. Давайте начнем! За последние несколько месяцев я и моя команда обсуждали написание приложения (как веб-приложения, так и мобильного приложения) с одной и той же кодовой базой, и мы прошли через множество дискуссий, исследований и аргументов. время, необходимое для первого выпуска приложения, возможность повторного использования и кривая обучения фреймворка.
Поскольку я сам был заядлым Android-программистом, я был склонен к кодированию на родной Java для Android, стеку MEAN для Интернета и следовал за приложением Cordova, которое заменит приложение для Android и iOS. Обоснование моей склонности заключалось в том, что я твердо верил, что гибридные приложения не смогут конкурировать с нативными приложениями. Более того, у нас уже есть некоторый опыт разработки в MEAN Stack. Это позволит команде быть в гораздо лучшей форме и сократить сроки по сравнению с изучением нового языка/фреймворка. Но поскольку я не хочу быть ограниченным своим узким умом и хотел бы бросить вызов самому себе, я отважился на одну из популярных платформ «Напиши один раз, используй везде», которой является метеор.
Итак, прежде чем я сам углублюсь в фреймворк, я провел небольшое исследование онлайн-форумов, stackoverflow и quora для сравнения и плюсов/минусов фреймворка метеора. К моему удивлению, очень мало сообщений в блогах поощряют использование метеора в качестве фреймворка для мобильных приложений. Но я бы сказал, что мы должны дискредитировать некоторые статьи, негативно относящиеся к фреймворку, поскольку они были рассмотрены и получили отзывы о первых годах существования метеора. Обычно они упоминают о нестабильности плагинов и мелких/крупных ошибках, как только приложение становится сложным.
Но мы согласились, почему бы нам просто сначала не попробовать, прежде чем что-то судить, потому что это никуда не годится. Итак, мы пробуем фреймворк, и нас обескураживают разные термины и кривые обучения. Мы обнаружили, что не очень хорошо знакомы со структурой и способом упаковки приложения метеором. Во время опробования мы обнаруживаем, что предыдущие ошибки, которые мешали другим, больше не являются проблемой, а скорее исправлены, и теперь фреймворк стал более адаптируемым.
Настоящая проблема возникает, когда мы пытаемся структурировать наш проект. Мы хотели бы структурировать большой проект с поддержкой как веб, так и мобильных устройств. И очень мало примеров и дискуссий на эту тему. Наиболее структурированный ответ/учебник, на который я хотел бы обратить внимание, — это социальное приложение с веб-сайта meteor-angular (https://www.angular-meteor.com/tutorials/socially). У этого есть довольно подробная структура папок о том, как иметь разные макеты для мобильных устройств и Интернета, но в то же время с использованием одной бизнес-логики. Даже тогда меня беспокоит, что в более поздней части приложения коды между мобильным и веб-приложением станут более зависимыми друг от друга, и их будет очень сложно поддерживать и понимать. Еще один важный фактор заключается в том, что для развертывания вы можете захотеть изучить расширенные API и методы упаковки, чтобы в вашем веб-приложении и мобильном приложении не было ненужных кодов.
Я бы не сказал, что фреймворк метеора плохой фреймворк, но я должен согласиться с тем, что если вы стремитесь к сложному проекту, вам может понадобиться немного больше подготовиться и иметь достаточно времени для компоновки проекта, чтобы он был легче работать в более поздней части проекта. Поскольку мы хотели бы выпустить наше первое приложение как можно скорее, нам не нужны эти накладные расходы. Итак, если бы у меня было достаточно времени, я бы сказал, что метеор — это платформа, в которую стоит вложить свое время.
PS: Это очень предвзятая точка зрения новичка в отношении структуры метеора, которая может быть неверна для всех. Мы решили использовать MEAN Stack + React Native для нашего проекта.
