tech stack что это
Что такое стек технологий. Объясняем простыми словами
Стек включает в себя языки программирования, фреймворки (программная среда для разработки), системы управления базами данных, компиляторы (переводят текст, написанный на языке программирования, в набор машинных кодов) и так далее.
Выбор конкретного стека зависит от архитектуры проекта, сложности и функциональности сайта, системных требований — какую выбрать операционную систему и систему управления базами данных, какой использовать веб-сервер и язык программирования.
Например, для веб-разработки стек технологий может выглядеть так:
Примеры употребления на «Секрете»
«ИТ-специалисты должны чётко представлять, что ключевое в EdTech — открытость API, возможность интегрироваться с другими платформами, а также использование современного стека технологий».
(Основательница Smart School Pro Елена Игнатьева — о типичных ошибках образовательных стартапов.)
«Если применить подход в лоб и ориентироваться только на цену, то вы рискуете получить команду, которая не даст вам искомых показателей эффективности. К примеру, при выборе рекламного агентства следует обратить внимание на размер и опыт команды, стек используемых технологий, клиентский портфель и отзывы».
(CEO Realweb Partners Эмин Аветисян — об ошибках офлайновых компаний при выходе в онлайн.)
Нюансы
Любое веб-приложение состоит из двух частей — клиентской и серверной. Клиентская сторона охватывает всё, что пользователи могут видеть на экране.
Важнейшие элементы технологического стека в клиентской части:
Серверная часть приложения готовит данные для клиентской части. Здесь придётся выбрать:
Выбранные технологии будут определять функционал продукта и то, можно ли будет его масштабировать в будущем. Также от выбранного стека будут зависеть оплата специалистов и время на разработку.
Если клиент планирует продавать одежду через небольшой онлайн-магазин, ему не понадобятся параллельная обработка больших объёмов данных (noSQL) и механизм распределения нагрузки (load balancing), заточенный на одновременную поддержку 1 млн пользователей. В то же время клиенту, который планирует продавать тысячи товаров в день, не подойдёт решение на базе бесплатного движка сайта (CMS) с дешёвым хостингом.
Выбираем правильный стек технологий для проекта
Тщательный анализ проекта поможет определить, какие технологии лучше использовать. Не стремитесь использовать те, в которых вы наиболее сильны. Этот простой принцип помогает развитию долгосрочных деловых отношений.
Результаты вашей работы будут влиять на все отделы и подразделения: от управления персоналом до маркетинга. У вас должно быть четкое представление, как что работает в компании клиента, какие отделы тесно взаимодействуют, а какие нет.
Перед написанием статьи, мы опросили разработчиков о чем они думают перед тем, как приступить к работе.
Результаты разделили на 3 блока:
Разработчик должен понимать концепцию продукта, изучить бизнес клиента и узнать временные рамки проекта.
Какой масштаб, бюджет и сроки проекта?
Клиент хочет добавить новую фичу за две недели или ему нужна ERP и это будет долгосрочный проект?
Эти вопросы позволяют узнать, реалистичны ли ожидания клиента, прежде чем вы начнете работать.
Это краткосрочный или долгосрочный проект?
Неважно, проект будет длиться месяц или пять лет, в любом случае, он должен быть сделан хорошо.
Важна ли техническая составляющая?
Здесь понадобится навык убеждения. Ваша ответственность в том, чтобы заставить их понять последствия игнорирования технической составляющей проекта в долгосрочной перспективе. Это покажет вашу заинтересованность в успехе проекта и повысит уровень доверия с заказчиком.
Насколько это должно быть безопасно?
Теперь на секунду задумайтесь о сфере деятельности клиента. Скорее всего, уровень секретности у всех будет разный. Технологии, которые вы выберете, должны это учитывать.
Есть категория клиентов, которые одержимы безопасностью. С ними действуйте осторожно. Некоторые из них слышат ужасные истории вне контекста, которые не дают им спать по ночам:
«Я уверен, что российские хакеры, которых я видел по телевизору, украдут список контактов нашего ресторана.”
Выбор технологий для большого и не очень большого веб-проекта
За годы работы я часто слышу вопросы о выборе технологий для того или иного веб-проекта. Кто-то спрашивает у нас, как у разработчиков, как правильно, а кто-то приходит и просит сделать на какой-то конкретной технологии. Проблема в том, что большинство выбирают технологии по субъективным причинам, и пока я не слышал достойного и понятного рассуждения, которое позволило бы выбрать технологию объективно, основываясь на фактах, а не желаниях. Даже немногие итишники могут правильно выбрать технологию, ведь для этого нужно: понимать специфику проекта, иметь многолетний опыт разработки на нескольких языках, знать, как устроены подобные проекты и т.д.
Но прежде, чем что-то выбирать, давайте посмотрим, какие технологии бывают, чем они отличаются и в каких случаях какую технологию выбрать.
Как чаще всего выбирают технологию сейчас:
В чем тут проблема:
Важные критерии при выборе технологий:
Какие бывают проекты
К технологиям мы еще вернемся, а пока давайте разберемся, какие бывают проекты. Часто тип проекта говорит сам за себя, и можно сразу сказать, что подойдет: либо уже готовое решение, либо хотя бы в какую сторону нужно двигаться.
По сложности проекты делятся:
Языки программирования
В технологиях я бы выделил 3 уровня абстракции:
Сегодня есть огромное количество разных языков программирования, на которых делают сайты. И, более того, на всех популярных языках есть примеры огромных сайтов. Если 10 лет назад, говоря о технологиях больших сайтов, все говорили преимущественно о Java, то сегодня это может быть почти любой язык, и утверждать, что сайты делаются на каком-то конкретном языке, — стереотип. Это связанно с развитием самих языков, за последнее десятилетие многие сильно продвинулись в развитии и получили широкие возможности. Конечно, каждый язык чем-то отличается, и выбирая мы опять же должны руководствоваться объективными критериями с оглядкой на задачи проекта.
На чистом языке, без использования фреимворков и коробочных решений, пишутся огромные проекты с повышенными требованиями по гибкости, нагрузкам и безопасности. Для таких огромных проектов часто бюджет не играет такого значения, как эффективность. Чем больше проект, тем больше будет требований по гибкости и нагрузкам, а значит, проще писать все с нуля, выделяя на это лучших специалистов, чем если брать какие-то готовые решения, которые непонятно кем писались и непонятно какие проблемы в них скрыты. К примеру, когда речь о небольшом проекте с посещаемостью в 10 тыс. человек в день, то нам будет дешевле сделать его на CMS, которая будет потреблять в 3 раза больше ресурсов сервера, поставить дополнительный сервер за 50$ / мес., и он будет работать. Когда же мы говорим о сайте с посещаемостью в 100 млн. пользователей в день, стоимость добавления серверов у нас будет просто космической, поэтому нам проще и дешевле вложить деньги в разработку решения на чистом языке, которое будет оптимальным именно для конкретного проекта.
Чем больше проект, тем больше стек технологий, который в нем используется. В огромных порталах может использоваться сразу несколько языков программирования. Опять же, мы приходим к объективным критериям выбора технологий. Часто один язык может хорошо решать одну задачу, а другой — другую. Такие проекты могут быть настолько огромными, что их части могут работать на разных серверах, с разными доменами (поддоменами) и разными технологиями. Не следует бояться винегрета технологий в большом проекте, хотя и допускать его нужно только, когда это действительно необходимо, а также помнить, что далеко не все технологии совместимы. Самый яркий пример использования разных технологий — Google. Он на столько большой, чтобы разные его части написаны на C/C++, Java, Python, JS и других языках. Более того, Google активно создает новые технологии, как, например, популярный нынче AngularJS.
Попробую дать краткую характеристику каждому из популярных языков:
Примеры больших сайтов:
Фреймворки и платформы
Это некая среда разработки для программистов, где есть готовая инфраструктура и ряд готовых функций со стандартными решениями типичных задач. Такой себе полуфабрикат, из которого можно сделать конфетку. На каждом языке есть много разных фреймворков. Есть как общие, которые создавались для разработки любых решений, так и специализированные, под узкие задачи. Например, Sylius — специализированный E-commerce фреймворк на основе Symfony. Также есть те, на которых делаются большие и сложные решения, а другие для этого не предназначены. Ниже я опишу популярные фреймворки для каждого из языков, на которых можно писать большие и сложные решения.
На фреймворках разрабатываются довольно большие и сложные сайты с уникальным функционалом. Это значительно быстрее и дешевле, чем на чистом языке, но при этом такое решение позволяет разрабатывать действительно сложные вещи и оптимизировать все это под нагрузки. Кроме того, это почти всегда более безопасно, чем любая коробочная CMS.
Популярные фреймворки и платформы:
.NET и Node.js — это целые самостоятельные платформы, которые базируются на определенных языках, но имеют очень широкие возможности.
Недавно мы проводили исследования по тем фреймворкам, на которых специализируемся. Смотрели в каких больших проектах они используются. В частности огромные сайты на Python / Django и огромные сайты на PHP / Symfony. Также мы писали, как мы разрабатывали социальную сеть на Symfony вместе с API (статья больше про API, самое широкое описание в рунете по этой теме). Такие же огромные сайты есть на каждом из перечисленных фреймворках.
CMS и CMF
Это готовое программное обеспечение, которое нужно только настроить, реже — дописать / переписать какую-то из частей. Таких решений очень много на любом языке, но исторически так сложилось, что в основном все популярные CMS сделаны на PHP. Тут дело в развитии языков, раньше простые сайты, для которых и создавались CMS, писались на PHP. Я еще застал те времена, когда CMS почти не было, были скрипты — отдельные готовые части разных сайтов. Позже эти скрипты собирали в коробочный продукт, который был призван решить потребности 90% простых сайтов. Так и получилось, что основные CMS сделаны на PHP. Сегодня CMS на других языках развиваются слабо, потому что уже есть сильные конкуренты на PHP, а для простого сайта язык не играет большой роли, поэтому все смотрят на возможности этих готовых продуктов.
CMF, если говорить простым языком, — это что-то среднее между CMS и фреймворком по возможностям. Обычно CMF используют для самых сложных сайтов из этой категории. Этот подход позволяет избавиться от лишних частей CMS, которые не нужны конкретному проекту.
CMS бывают разные по назначению: общие, для интернет-магазинов, для блогов и т.д. Разные по условиям использования: платные и бесплатные. Для каждой популярной CMS есть много разных платных и бесплатных модулей, которые легко подключать и использовать.
Маленькие сайты, которые в основном нужны для малого бизнеса, почти всегда используют CMS. Это позволяет очень сильно экономить время на разработку. Кроме того, для настройки таких решений не нужны дорогие программисты, обычно это могут делать новички в программировании, по крайней мере саму настройку, если уже нужно писать код, тут сложнее.
Именно в работе с CMS возникает больше всего непонимание среди конечных заказчиков таких решений. Любая CMS — это тонны готового программного кода, на все случае жизни. В коробочной поставке идут десятки и сотни модулей. Все это очень сильно ограничивает специалистов. Такие решения сильно «тормозят», они абсолютно не гибкие, их очень легко взломать, особенно бесплатные CMS. Еще часто взламывают CMS через модули сторонних разработчиков, в которых есть критические уязвимости, потому что мы никогда не знаем, какого уровня программист писал тот или иной модуль. То есть любая CMS НЕ рассчитана для большого и сложного сайта. Она не может выдержать большие нагрузки. Это решение небезопасно, чтобы не говорили разработчики конкретной CMS.
Я видел решения почти на всех популярных CMS, с многими за более, чем 10 лет работы, пришлось поработать лично. Часть из них популярна в рунете, а часть знают в основном на западе. На используемые в них языки CMS разбивать нет смысла, по причинам, описанным выше. Лучше сказать несколько слов про каждую популярную CMS:
Ранее, мы проводили исследования, на каких CMS сделаны самые посещаемые сайты рунета: часть 1 и часть 2, крупнейшие интернет-магазины и крупнейшие сайты банков. Эти исследования подтверждают описанные выводы в статье.
Шаблоны
В последние 5 лет очень активно развивают шаблонные решения. Это еще на одну ступеньку выше, чем CMS. Если CMS — это конструктор, и его нужно настраивать, то шаблоны — это уже готовые решения под типовые случаи. Например, в каждом городе есть свои рестораны, такси, клиники и т.д. Для всех этих типов малого бизнеса нужно примерно одно и тоже. Поэтому, можно просто выбрать готовый тематический шаблон, заменить в нем логотип, цвета и контент. При желании такие шаблоны можно дорабатывать по усмотрению владельца.
Преимущества таких решений в том, что они очень дешевые и их можно запускать моментально. Но при этом такие решения не учитывают особенностей бизнеса и конверсия будет не очень высокой.
Есть специальные каталоги шаблонов: TemplateMonster, ThemeForest и др. Часто встречаются онлайн-конструкторы, в том числе тематические: Wix, PageCloud и др.
Мобильные приложения
В мобильных приложениях в последнее время используется два подхода: нативная разработка и кроссплатформенные технологии. Нативная ведется на оригинальных языках программирования, в частности Swift (для iOS, ранее был Objective-C) и Java (для Android). Кроссплатформенных технологий сейчас довольно много, они есть на базе разных языков программирования, в частности: Apache Cordova, React Native и др. Некоторые лучше, некоторые хуже. В любом случае, сложные приложения всегда пишутся на нативных технологиях. С кроссплатформой часто возникают проблемы, вплоть до того, что некоторые функции просто нереализуемы на тех или иных кроссплатформенных технологиях, сильно грузится оперативная память устройства, быстро садится батарея и т.д.
В этих двух подходах люди тоже часто путаются, пытаясь использовать кроссплатформенные технологии на все случаи жизни. Оно и понятно, ведь кроссплатформа позволяет писать код один раз, который сразу работает и на iOS, и на Android, в то время, как на нативных технологиях это выходит минимум в два раза дороже. Однако мало кто знает о возможных дальнейших проблемах в разработке. Я бы рекомендовал очень тщательно выбирать технологии, и кроссплатформу брать только для простых приложений, иначе придется переписывать. Впрочем, кроссплатформенные технологии постепенно развиваются и становятся все лучше, а приложения, написанные на них, все сложнее.
Стек технологий в больших проектах
Выше я описал разные языки и фреймворки, которые используются в больших проектах, однако, если присмотреться к действительно большим проектам, там можно найти целый комплекс языков и технологий. Почти все большие сайты используют один основной язык и несколько дополнительных. Тоже самое с базами данных: для одних задач могут использоваться реляционные, а для других нереляционные базы. И все это органично сочетается в рамках одного проекта.
Выбор технологий зависит от предлагаемой архитектуры проекта. Именно архитектор продумывает основные блоки будущего сайта. Какой язык ляжет к основу, будет ли он нативным или фреймворк, какую систему кэширования выбрать, какие базы данных, как все это будет связано и т.д.
Для примера рассмотрим технологии Instagram (данные Insight IT):
Стоимость специалистов
Один из важнейших факторов выбора технологии является стоимость и доступность специалистов, потому что именно это — самая затратная часть в любом проекте. В рунете есть только одна пузомерка по зарплатам: https://jobs.dou.ua/salaries/ — я отфильтровал по Киеву, уровень Senior, опыт 3-5 лет. Сравним средние значения.
Теперь переведем цифры на человеческий язык. Java хоть и не новый язык, но специалисты на нем всегда были одними их самых дорогих. PHP всегда был самым дешевым, да и специалистов на рынке очень много. В сравнение я внес еще и Scala, как один из новейших и трендовых языков, по этой причине он дороже всех. Еще дорогой JS, это связанно с его бурным ростом в последние годы и растущей популярностью Node.js, а также AngularJS.
Таким образом: если мы хотим экономить, то лучше смотреть на PHP — специалисты дешевые, а комьюнити большое. А если хотим самое качественное, то смотрим на Scala, который называют будущем веб-разработки, но, правда, на нем найти специалистов почти невозможно, и наработок просто нет.
Еще важным параметром будет скорость разработки. Ведь важна не только зарплата программистов, но и скорость разработки. Если не учитывать уже существующие наработки, то одними из самых быстрых в разработке будут Python и Ruby, а самый медленный — Java. Кстати, по этой причине за последние 10 лет почти не вышло новых мегапроектов на Java, зато вышло много проектов на Python, о чем я расскажу ниже.
Тренды
Выбирая технологию, нам нужно смотреть вперед. Особенно, если речь о большом проекте. Все технологии очень быстро развиваются, выходят все новые и новые версии. Языки сильно меняются каждые 5-7 лет, фреймворки — каждые 2-3 года, а CMS — каждые 1-2 года. Важно выбрать не просто хорошую технологию сегодня, а предугадать тренды развития так, чтобы остаться на коне и через несколько лет. Иначе, в конечном счете, придется переписывать проект, что всегда очень проблематично.
Есть всевозможные исследования, которые нам могут подсказать некоторые статистические выкладки. Например, исследование TIOBE Index показывает интересную статистику:
По результатам разных исследований можно выделить явных лидеров по росту — это JS (версия ES6 и выше) и мультипарадигмальные языки, в частности Scala. Кстати, именно Scala считается преемником языка Java и во многом на него похож. Также не плохо себя показывает Python.
Антитренды держат ряд старых языков и PHP. Правда, недавно вышла 7я версия PHP, в которой исправлены многие серьезные недостатки. Так что, я думаю, мы скоро увидим новый виток развития PHP. Также многие большие проекты переписываются с Ruby на другие языки, тоже некий антитренд.
Для иллюстрации посмотрим, каких специалистов не хватает в США:
Именно это можно считать реальной картиной трендов, которые мы видим и у нас.
На чем делались большие проекты за последние 10 лет?
Стоимость поддержки
Безусловно, важный критерий выбора технологии — это стоимость поддержки, о которой мало кто задумывается в начале разработки. Обычно все мыслят категориями стоимости часа поддержки, что в корне неправильно. Нам важны несколько параметров: стоимость часа, количество часов, официальная поддержка технологии, доступность специалистов, правильный подход к разработке и некоторые другие.
Стоимость часа зависит от зарплаты специалисты, с этим мы уже разобрались. А вот количество часов зависит от самой технологии и качества написания кода. Если решение коробочное, то часов на него может уходить очень много. То есть, с одной стороны, мы можем сэкономить при разработке первой версии проекта, но после погрязнуть в его постоянной доработке. Хорошо, когда решение популярное, и есть официальная документация. Но часто выбирают малоизвестные коробочные решения без какой-либо документации — в таких решениям стоимость поддержки будет во много раз выше стоимости самой коробки. То же касается некачественной разработки: у нас почему-то полностью отсутствует культура проведения технических аудитов готовых решений или их частей. В среднем за 20-40 часов можно проверить почти любое решение и найти его основные минусы. Чем более качественный код, тем легче, а следовательно, и дешевле его поддерживать.
Также следует смотреть на версию языка, фреимворка, CMS. Нужно всегда использовать самую последнюю стабильную версию, чтобы она не устарела до выхода проекта в продакшн. При появлении новой версии нужно сразу рассматривать возможность перевода проекта на эту версию. Потому что, если пропустить несколько версий, потом будет проблемно сделать резкое обновление.
Так что выбрать?
Подведем итог. Для простых сайтов чаще всего отлично подходят коробочные решения и шаблоны. Сложные сайты делаются только на фреимворках или даже чистых языках программирования. Делать можно на очень разных языках, язык выбирается под проект. Простые мобильные приложения можно делать на кроссплатформенных технологиях, а сложные обычно делаются на родных технологиях. Ну и, выбирая платформу, всегда стоит руководствоваться объективными критериями, которые я описал в статье.
Ниже я сделал опрос по предпочтительному языку программирования для большого проекта. Подразумевается уровень проектов с посещаемостью в 100 млн. пользователей и больше. Если у вас есть опыт разработки больших проектов, хотя бы на несколько миллионов пользователей, прошу не просто проголосовать, но и обосновать свое мнение в комментариях, так как у каждого разные опыт и предпочтения. Разбавим некоторую долю субъективизма статьи мнениями других членов сообщества 🙂
P.S.. В нашей школе есть несколько интересных курсов по программированию. Чтобы записаться пишите на info@digitov.com
P.P.S. Чтобы получать наши новые статьи раньше других или просто не пропустить новые публикации — подписывайтесь на нас в Facebook, VK и Twitter.
Автор:
Никита Семенов, CEO, Компания «SECL Group»
Как правильно выбрать стек для своего проекта?
Процедура запуска любого IT-приложения требует предварительной планировки и принятия решений на начальных стадиях его развития. Для заказчика данный проект должен быть результативным, и чтобы добиться его эффективности, разработчику понадобится подходить к выполнению задачи комплексно, обращая внимание на множество важных критериев.
Ключевое условие грамотного решения проблемы – не ошибиться в выборе стека технологий. Материал о том, что собой представляет технологический стек, а также о факторах, на которые нужно опираться, выбирая его, пользователи, постигающие науку веб-программирования, найдут в этой статье.
Под термином «технологический стек» понимают сложную комбинацию, включающую языки программирования, программное обеспечение и спектр фреймворков, применяемых для разработки IT-проекта.
Архитектура любого web-приложения включает две стороны – клиентскую и серверную. Требования к функционалу этих обеих сторон предусматривают смену вышеупомянутых средств разработки, то есть они непосредственно влияют на стек технологий.
Клиентской частью считаются визуализирующиеся данные, доступные пользователям на дисплее, которые используются посетителями сайта. Структура данной зоны IT-проекта представлена следующими базовыми компонентами:
· языком программирования, отвечающим за интерактивную часть web-проекта (JavaScript);
· языком разметки документации, позволяющим достоверно отображать содержимое сайтов в браузере (HTML);
· формальным (табличным) языком, обеспечивающим грамотную стилистику контента (CSS);
· UI-фреймворками и библиотеками (jQuery, Angular).
Технологии JavaScript, HTML и CSS применяются и с другими фреймворками – проектируя клиентскую часть, разработчики нередко используют React.js либо Bootstrap.
Серверной зоной веб-портала, не видной его посетителям, обеспечиваются данные зоны клиентской, расположенной над ней.
Разработка серверной стороны предполагает применение следующего «инструментария»:
· баз данных (например, MongoDB, Neo4j);
· языка бэкэнд-программирования (типа С #, Python либо Java);
· фреймворков, надстроенных над программными языками (NET или Spring);
· web-сервера (вариантом может быть и проект с архитектурой бессерверной);
· облачных инфраструктур и сервисов (Microsoft Azure, Heroku).
Требования к обеим частям (их называют соответственно Front-end и Back-end) должны заранее утверждаться и приниматься в процессе создания стека технологий.
Выбирая стек, необходимо учитывать шесть ключевых аспектов.
1. Специфику самого IT-проекта.
Речь идет об учете размеров и целевого назначения веб-приложения – выбирать технологии надо, опираясь на эти моменты. Для маломасштабных, одностраничных веб-сайтов подойдет стек Node.js-React. Средние по величине веб-приложения сайтов интернет-магазинов или подобных коммерческих порталов нуждаются в стеках большей сложности, включающих несколько уровней языков программирования и несколько фреймворков. Для созданий крупных проектов потребуется самый масштабный стек, способный работать со значительными объемами данных, поддерживать необходимый уровень производительности web-приложений и их целостность.
2. Опыт и ресурсный потенциал.
Правильный подбор технологий предполагает компетентность разработчика, обеспечивающую ориентацию специалиста в тонкостях и отличиях каждого из стеков. Лучше web-программисту делать выбор в пользу «объезженных», хорошо известных ему технологий. Испытанные решения надежнее новых, для реализации которых понадобится дополнительное время и силы. Однако стоит помнить, что технологии «вчерашнего дня», которые явно устарели, – тоже не лучший вариант. Они могут снизить эффективность приложения и повлечь за собой сложности, связанные с технической поддержкой.
3. Масштабируемость приложения.
Актуальным звеном проекта, позволяющим справляться веб-сайту с нагрузками, например, стремительным притоком трафика, является масштабируемость его архитектуры. Различают масштабируемость горизонтального и вертикального типа. Первый тип открывает доступ к приложению с разных устройств и рассчитан на рост посетителей. Второй – предусматривает возможность добавления новых функций и компонентов на портал в будущем.
4. Уровень безопасности.
Безопасность личных данных пользователя важна для любого приложения, но, если сервис предусматривает онлайн-платежи, формируя стек, стоит отдавать предпочтение выбору технологий, обеспечивающих максимальную безопасность, недоступность для кибератак.
5. Удобство обслуживания web-приложений.
Для архитектуры проекта важна мобильность и возможность повторного применения, а для его кодовой базы оптимальна средняя длина: на обработку длинного кода будет уходить много времени, а код слишком короткий может вызвать при дебаге ошибки.
6. Сроки разработки.
Если сроки выполнения проекта сжаты, целесообразно руководствоваться готовыми решениями технологического стека. Такой выбор обеспечит простую интеграцию, и сведет время работы над проектом к минимуму.
В число популярных готовых решений технологий, упрощающих работу команды web-специалистов, входят стеки LAMP, MEAN, MERN и MEAN. Такие модели, обретшие популярность, подходят для разработок многих веб-приложений среднего и крупного масштаба. Но данный факт не означает, что соответствующие стеки универсальны: применить их к абсолютно всем проектам нельзя – специализированные веб-приложения требуют не привычного, а креативного подхода.
Условие правильного выбора стека – скрупулезное предварительное изучение базовых функций, предназначения разрабатываемого web-приложения