Как выбрать стартовый стек

Хм, 3/5 Нет, это не очень позитивный прогноз. Так что еще я знаю? Javascript, но я никогда не создавал что-то значительного размера, но мне это понравилось. Я получил несколько советов по Ruby, они утверждали, что его легко выучить, но все же огромная авантюра, чтобы начать что-то новое. Расспросив вокруг, я также обнаружил, что спрос на Ruby-разработчиков в Барселоне безумно высок, что выражается в высоких зарплатах, что недоступно на первых этапах реального стартапа.

Заглянув в Интернет немного дальше, я наткнулся на некоторые другие языки, которые продаются из-за низкой кривой обучения, например Go и Python. Python довольно популярен, Go нельзя сравнивать со многими другими языками.

Javascript означает один язык для всего стека, это был мой второй по силе навык на тот момент, его чрезвычайно дешево размещать, его знают многие разработчики или, по крайней мере, основы (доступный найм), кривая обучения, на мой взгляд, вполне нормальная и это легко загрузить. Это как почти 5/5 "Да", тогда это будет JavaScript!

Фреймворки и BaaS

Теперь, когда мы разобрались с этим, я провел небольшое исследование Backend-as-a-service и (самоуверенных) фреймворков. Они могут ускорить время разработки, чтобы наша продукция соответствовала требованиям рынка. Не забывайте, скорость имеет решающее значение, поскольку денег очень мало. Рабочий прототип, который может приносить доход или соответствовать требованиям рынка, важнее надежной архитектуры, но на данном этапе для компании нет пользователей.

• Firebase. Полный реактивный стек, довольно приятный, потратил на это два дня на взлом, имеет множество функций и услуг, которые поставляются из коробки, но сочетание привязки к поставщику и Ограниченная свобода бэкэнда создала у меня впечатление, что это не будет разумным выбором. Я заранее знал, что в нашем решении будет много внутренних процессов, поэтому мы решили использовать чат-бота в качестве исходного пользовательского интерфейса. Поэтому не уверен, что реактивные функции будут полезны.
• Meteor: как Firebase, полностью реагирующий, но очень самоуверенный. Возможности хостинга были ограничены, также немного потрудился с ним, чтобы опробовать его. Те же ограничения, что и у Firebase; привязка к поставщику и на более позднем этапе трудно отказаться от этой архитектуры. Принимая во внимание чат-бота, если бы нам в основном понадобился REST api, казалось очевидным, что это не интересный вариант.
• NodeJS: медленнее для начальной загрузки по сравнению с Firebase и Meteor, но архитектура / фреймворк, вероятно, выживут в долгосрочной перспективе, без привязки к поставщику, но с бесконечными вариантами хостинга. Поскольку сначала мы начинали с чат-бота, мне не понадобились многие специальные функции Firebase и Meteor, поэтому NodeJS казался хорошим вариантом наряду с KoaJS v1 из-за поддержки генератора для работы с обещаниями. На этом этапе async / await еще не был готов к производству в Node.

База данных

Отлично, теперь у нас есть язык и фреймворк для начальной загрузки нашего проекта! Что осталось… база данных! Как и в предыдущих решениях, это было нелегко. Большинство людей выбирают MongoDb в NodeJS, но было ли это действительно мудрым решением? Я изучил множество вариантов, но давайте выделим самые важные из них:

• RethinkDb: реактивная база данных, довольно удобные функции. Я играл с ним какое-то время, он мне очень понравился, но в то время сообщество было очень негативным. Основные участники или компания, которая поддерживала RethinkDb, только что объявили, что планируют прекратить ее поддержку, они опубликовали в своем блоге сообщение о том, что разговаривают с потенциальными клиентами, которые будут заинтересованы во взятии проекта на себя. В дополнение к этому, я читал много разочарований сообщества относительно низкой активности в коммитах и ​​утверждениях запросов на вытягивание. Это заставило меня отойти от этого.
• PostgreSQL: надежное ядро ​​базы данных с поддержкой документов наряду с SQL. Поскольку мы собирались работать с финансовыми процессами, мне очень понравилась поддержка транзакций в старой доброй базе данных SQL. Этот движок базы данных уже зарекомендовал себя ветераном. Я слышал много положительных отзывов об этом относительно скорости, стабильности, и я знаю довольно много компаний, которые перешли с MongoDB на PostgreSQL, когда их продукт стал достаточно зрелым и перестал соответствовать требованиям рынка.
• MongoDb: для баз данных документов это самая популярная и достаточно хорошо развивающаяся база данных. Он имел хотя бы некоторую поддержку запросов с левым соединением, и снова синтаксис очень естественный для Javascript, что всегда приятно. Этот механизм базы данных имеет хорошую документацию и активно поддерживается, а также многие доступные варианты хостинга.

Я провел бесчисленное количество часов, выбирая между PostgreSQL и MongoDB. У них обоих есть свои за и против. У меня начинало заканчиваться время, и я должен был принимать решение. Я обсуждал плюсы и минусы с друзьями и советниками. Идеальный вариант использования MongoDb - это хранение неструктурированных данных, которые вы можете получить из внешнего API.

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

В конце концов я решил перейти на MongoDb. Я знал, что в первые месяцы создания прототипа продукта модель данных будет меняться бесчисленное количество раз, и я не хотел терять время на выполнение сценариев миграции SQL после каждое локальное изменение и развертывание производства. Один человек однажды сказал мне во время обсуждения: «Легче перейти с Document на SQL, чем наоборот», может быть, а может и нет, но это интересный момент.

Это было решение с небольшим отрывом, время шло и надо было начинать работу над продуктом. До сегодняшнего дня я все еще обдумываю решение, но время идет, я знаю, что трачу приличное количество времени на взвешивание всех «за» и «против». Пришло время двигаться вперед.

Фреймворк для внешнего интерфейса

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

• Angular 2. Я экспериментировал с Angular 2, когда был соучредителем Nexpat, но он произвел на меня сильное впечатление из-за крутой кривой обучения. В тот момент, когда я впервые экспериментировал с Angular 2, который был в бета-версии, мне пришлось многому научиться. Оглядываясь назад, я теперь знаю, что это произошло потому, что я был еще новичком в Javascript, а Typescript вместе с изучением парадигмы Angular 2 были для меня в новинку, так что я узнал много нового вместе. В то время это могло омрачить мои суждения.
• Angular 1: я использовал это в небольшом одномесячном проекте (после того, как поигрался с Angular 2 @ Nexpat), когда я создавал небольшое приложение с фреймворком Ionic. У меня была более низкая кривая обучения из-за отсутствия TypeScript и моего более обширного опыта работы с Javascript.
• ReactJS: пока я подал заявку на работу, мне пришлось сделать небольшой проект на ReactJS в качестве технического теста. Мне это понравилось, кривая обучения была довольно низкой, и сообщество к этому моменту процветало.
• VueJS: никогда раньше не слышал об этом, но один из наших консультантов, Майкл Карлинер, рассказал мне об этом. «Сначала я сомневался, - подумал я, - черт возьми, еще одна новая структура». Но после создания нескольких мини-прототипов мне очень понравилась документация, как она работает, шаблоны handelbars и низкая кривая обучения.
• EmberJS: [отредактируйте 2, забыл этот]. Мы использовали это в предыдущей компании, в которой я работал, я однажды экспериментировал с этим. В тот момент кривая обучения казалась немного крутой. Но теперь знайте, что это было скорее из-за незрелости моих навыков Javascript на тот момент. В Ember есть такие передовые практики, как JSON API и тому подобное, поэтому я бы посоветовал любому хоть немного поэкспериментировать с ним.

Будучи последним «важным» решением в стеке, я провожу бесчисленные часы, читая блоги по темам Angular, React и VueJS. После тщательного чтения и обсуждения с другими разработчиками я решил перейти на VueJS.

У VueJ была самая низкая кривая обучения из всех, хорошее живое сообщество и отличная документация. Пользоваться им стало просто удобно. Я не спорю, что другие фреймворки лучше или нет. Это была как раз подходящая структура для меня, у меня уже было так много дел, что мне нужно было выбрать что-то, что было бы легко изучить и понять, чтобы я мог двигаться быстро.

Меня беспокоило только то, что он был очень новым / молодым. Это всегда риск, который следует учитывать. Еще одним преимуществом VueJS было то, что у них есть официальные дополнительные библиотеки для маршрутизации и управления состоянием. Это означает, что они, скорее всего, не внесут никаких сумасшедших критических изменений, которые сделали бы библиотеки несовместимыми друг с другом.

Отражение

Вот и все, полный стек:

• JavaScript
• NodeJs
• MongoDB
• VueJS

Когда я посмотрел на последний стек, я действительно занервничал. Это действительно похоже на решение о стеке, вызванное ажиотажем, не так ли? Разве я позволил себе соблазнить себя новыми блестящими горячими вещами? Правильно ли я принял решение для этого стартапа? Был ли я жертвой предвзятости подтверждения? Честно говоря, это меня действительно напугало.

Сожалею ли я о своих решениях? Нет, конечно, нет. Я знаю, что потратил много времени на изучение всех вариантов. Я взвесил все «за» и «против» каждой технологии и провел обстоятельные обсуждения со старшими разработчиками. Я много занимался прототипированием, чтобы сравнить разные фреймворки и технологии.

Принимая во внимание все интересы Saveboost с потенциалом успеха, я чувствую, что сделал хороший выбор в меру своих возможностей.

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

Изменить 1: после некоторой обратной связи я понял, что не упомянул ничего о кривой обучения базам данных. Преимущество SQL заключается в том, что большинство выпускников имеют хорошие базовые навыки работы с рациональными базами данных. Таким образом, для большинства потенциальных сотрудников это было бы невысоким входом, базы данных документов не распространены в учебной программе степени информатики (по крайней мере, когда я учился). Однако MongoDb имеет очень хороший собственный API-интерфейс Javascript, что означает минимальную загрузку, но другую философию по сравнению с SQL.

Мы будем благодарны за любые комментарии и отзывы. Какой стек вы выбрали? Почему? Каковы были ваши решающие факторы? В чем вы сомневаетесь в своем выборе? Какие требования вы учли? Я очень хочу получить известие от вас.