Работая в разных стартапах, а также управляя проектами в качестве фрилансера для стартапов, которые находятся на нулевом уровне, я видел, как многие люди обращаются к первокурсникам для создания внешнего и внутреннего интерфейса, поскольку это не будет стоить им так много, когда то же самое будет создано опытным разработчик, но они забывают, что первокурсники не знакомы с лучшими практиками и вещами, которые следует знать при создании серверного REST API или использовании его во внешнем интерфейсе, будь то любой фреймворк.
Я видел много ошибок и технических долгов в нескольких кодовых базах, созданных новичками, и это не вина, их не учат этим практикам, поэтому в этой статье я попытаюсь сосредоточиться на нескольких вещах, которые я видел и чему научился. проекты производственного уровня.
Бэкенд (REST API)
Начиная с бэкенда, где я проработал большую часть своей карьеры программиста. Я сосредоточусь на Node.js, но я также работал и с другими языками, поэтому я думаю, что некоторые моменты можно использовать в других языках или фреймворках —
- Использование простых строк для сохранения паролей.Создать что-то с помощью простых строк легко, но это очень плохая практика, особенно если это пароль. Доступны пакеты, которые будут хэшировать ваш пароль — bcrypt является одним из них и наиболее популярен в Node.js, а также доступен в Golang. Python предоставляет hashlib, а также вы можете использовать scrypt. Если вы используете полноценный фреймворк, поищите документацию, которая по умолчанию предоставит вам хэш.
- Нене отправлять зашифрованный пароль в API —Отправка хэшированного пароля в API — плохая практика, даже если это займет бесконечное количество времени, чтобы расшифровать пароль с помощью грубой силы, все еще не не делай этого.
- Проверять пользователей с помощью токена.Легко просто сопоставить имя пользователя/адрес электронной почты или любой уникальный идентификатор и пароль, будь то строка или сравнить хеш-строку, а затем вернуть весь объект пользователя, но это не так хорошо, как хотелось бы. авторизовать маршруты только для определенного пользователя или специально для пользователей, которые вошли в систему. Также этот токен может использоваться внешним интерфейсом для хранения в локальном хранилище, а при повторном посещении автоматически аутентифицируется вход человека. JSON Web Token (JWT) является стандартным для этого, и все основные языки и фреймворки предоставляют библиотеки для JWT.
- Использовать базу данных с самого начала проекта — я видел людей, использующих SQLite для хранения данных в серверной части, и мой вопрос: почему? SQLite не предназначен для этого. Используйте правильную базу данных с самого начала и оцените преимущества использования обеих баз данных SQL/NoSQL, прежде чем начать использовать одну из них. Вот статья от GeekforGeeks об основных отличиях. Я знаю, что настроить базу данных сложно, вы можете использовать Docker для контейнеризации баз данных, что поможет в тестировании на локальном уровне, а также поможет в изучении Docker.
- Используйте ORM — вы можете быть очень опытным в написании SQL-запросов или запросов Mongo, но по мере того, как эти проекты становятся все больше и больше, написание простых SQL-запросов может стать утомительным, вы можете совершать множество ошибок, а также это будет стоить вам времени. . ORM упрощают работу с базами данных, а также создают модели или схемы, которым следует следовать при чтении и записи данных. ORM также предоставляют удобные функции для предложений SQL и соединений между таблицами или ссылками на коллекции.
- Использование переменных среды.Используйте переменные среды для хранения важных вещей, таких как учетные данные для сторонних API, ключи API, секреты, URL-адреса баз данных и другие важные вещи. Каждый язык программирования предоставляет способы доступа к переменным среды — в Node.js process.env.varibable_name, в Python os.environ[‘variable_name’], в Golang os.Environ(‘variable_name’). Поскольку большинство серверов работают на Linux, очень легко установить переменную среды, будь то оболочка bash или оболочка zsh (в среде разработки) — export variable_name=value
- Подумай раньше — я видел людей, создающих конечные точки API со случайными именами. Подумайте, прежде чем создавать конечную точку API, и назовите ее с умом, чтобы люди, которые будут работать над ней позже, могли легко понять, с каким API они работают, а также знали методы HTTP.
- Знать методы HTTP.Перед созданием любого API изучите четыре основных метода HTTP и их функции. Это GET, POST, PUT и DELETE. Как следует из названия, они делают то же самое: GET для получения данных о конкретной вещи, POST для добавления или создания записи в базе данных, PUT для обновления определенной записи в базе данных и DELETE для удаления записи из базы данных. Используя POST для каждой операции и называя свои конечные точки, такие как «/addpost», «/getpost», «/updatepost», «/deletepost», вы можете легко создать единую конечную точку «/post» со всеми этими методами. GET /post получит все сообщения, GET /post?title=”название определенного сообщения” отправит все сообщения, соответствующие параметру, POST/post добавит сообщение, PUT /post/:id или /post?id=” уникальный идентификатор поста» обновит конкретный пост, DELETE /post/:id или /post?id=»уникальный идентификатор поста» удалит этот конкретный пост.
- Научитесь использовать параметры URL —продолжение до последней точки, научитесь использовать строку запроса. Это очень полезно, например, когда вы отправляете запрос GET, чтобы найти конкретную информацию в базе данных, например сообщение, вы можете отправить его в строке запроса, например GET /post?title="название сообщения". Делать POST-запросы для всего — плохая практика, которая может увеличить количество конечных точек, которые вы создаете.
- Подумайте о разбиении на страницы.Разбиение на страницы является основной потребностью в каждом REST API. Мыслить и создавать REST API, сохраняя преимущества в долгосрочной перспективе по мере роста данных, ваше приложение может быть готово к обработке больших данных.
- Изучите основы, но используйте фреймворки.Изучите основы серверной части веб-разработки на языке, который вам нужен, но я считаю, что использование фреймворков, когда дело доходит до создания серверной части производственного уровня, поскольку они предоставляют встроенные лучшие практики, они могут быть самоуверенный, но я думаю, что иногда полезно иметь мнение, особенно от людей, которые более опытны, чем вы. Несколько примеров таких фреймворков, как Node.js, имеют Nest.js, Sails.js, Meteor.js, Express.js, Hapi, Koa. У Python есть Django и Flask, у Golang есть Gin, Beego, Mux, Buffalo, у Java есть Spring/Spring Boot.
Специально для Node.js
- Используйте ES6 —используйте синтаксис ECMAScript 2015 или ES6 и найдите поддержку ES6 в Node.js. Если версия V8 поддерживает его, то он будет поддерживаться Node.js для конкретной версии. Хорошее место, чтобы посмотреть на это эта ссылка.
- Используйте машинописный текст.Конечно, машинописный текст создает некоторые накладные расходы на настройку среды разработки, но хорошо получать ошибки во время компиляции, а не во время выполнения.
Внешний интерфейс (Интернет)
Угловой 2+
Разделение кода Angular очень хорошо из коробки, используйте функции, предоставляемые фреймворком, и лучше всего то, что он используется самим Google для создания собственных продуктов, и они тестируют их перед выпуском для широкой публики.
- Используйте сервисы. Я видел распространенную ошибку, когда люди вызывают API непосредственно из самого компонента. Компонент должен обрабатывать только данные представления и делегировать доступ к данным службам.
- Используйте хранилище, когда это необходимо.Службы могут делать большинство вещей, которые могут делать библиотеки управления состоянием, но когда вы видите, что состояние становится более сложным, лучше перейти в библиотеку управления состоянием, пока не стало слишком поздно. Один из любимых
ngrx/storeсообщества - Использовать функции машинописного текста — Typescript великолепен, он сопряжен с некоторыми накладными расходами при настройке, но если вы используете Angular, то он поставляется из коробки, то почему бы не использовать их, например, проверку типов во время компиляции, хороший редактор поддерживает мало среди многих.
- Использовать защиту — не брать на себя накладные расходы на создание условия else if, чтобы передать логику для защиты того, доступен маршрут или нет. Лучше написать это один раз, а затем использовать их в любом маршруте, который вы хотите.
- Используйте CLI —Angular предоставляет один из лучших интерфейсов командной строки, вы можете создавать все, что связано с Angular, просто используя CLI, будь то компоненты, службы, средства защиты и т. д. Кроме того, это экономит время, так как при создании компонента вы получаете html, ts, specs и css, созданные за один раз, с написанным базовым шаблоном и компонентом, добавленным к импорту модуля.
- Использовать файл окружения — Angular предоставляет удобный способ определить, в каком окружении он работает, и соответственно построить его. Существует много этапов разработки, таких как разработка, подготовка, UAT, производство, и в каждом файле можно определить разные ключи, базовую конечную точку API и т. д., а затем изменить angular.json, чтобы проверить process.env и использовать файл среды соответственно.
- Использовать моделирование данных. Это особенно важно, если вы не используете Node.js в качестве серверной части, даже если вы это делаете. Я думаю, что рекомендуется моделировать данные, которые будут быть показаны. Подобно бэкэнду, может потребоваться, чтобы ключи были в змеином регистре, когда вы следуете за верблюжьим регистром во внешнем интерфейсе, создаете класс и имеете функции для их сериализации.
- Используйте Angury. Angury — это расширение инструмента Google Chrome Dev для отладки приложений Angular, но не только для Google Chrome, теперь оно также доступно для Firefox. Иди проверь это круто.
Реакция
React — еще один популярный интерфейсный фреймворк, который предоставляет разработчику открытую платформу для использования библиотек, которые они хотят, но я видел ошибки людей.
- Axios interceptor —Axios — самая популярная библиотека для создания HTTP-запросов, но мало кто знает, что в axios есть концепция перехватчика, где вы можете определить базовую конечную точку и другую логику, такую как добавление токена авторизации. и т.д. Ссылка
- Использовать управление состоянием — я усвоил это на собственном горьком опыте, когда столкнулся с проблемой управления большими состояниями приложения и передачей реквизитов вглубь дерева компонентов. Да, настройка сложна, но когда приложение растет, первоначальная настройка окупается.
- Различайте компоненты и страницы.React не предоставляет готового решения для разделения кода, и это приводит к беспорядку, если вы не развиваете мышление о будущем. Если вы создаете поле для комментариев, создайте его один раз и используйте в разных случаях, что очень распространено в соответствии с принципом DRY. Имейте разные папки, такие как компоненты и страницы, как я это делаю.
- Используйте машинописный текст — я знаю, что слишком много внимания уделяю машинописному тексту, на самом деле это хорошо, также реагируйте CLI поставляется с флагом для начальной загрузки вашего проекта с помощью машинописного текста.
- Используйте инструменты React Dev.Подобно Augury, у React также есть расширение инструмента разработки для Chrome и Firefox.
Не зависит от платформы
- Научитесь использовать инструменты разработки.Chrome и Firefox имеют очень хорошие встроенные инструменты разработки. Научитесь их использовать. Что бы вы ни хотели узнать о своем веб-приложении, будь то сетевой запрос, проверка элемента в дереве DOM, просмотр локального хранилища или кеша, проверка работоспособности сервисного работника, они просто потрясающие. Кроме того, инструменты разработчика Chrome лучше всего предоставляют вам Lighthouse, проверяя ваше веб-приложение на основе передовых методов, таких как загрузка страницы в медленной сети, готовность приложения к PWA или нет, даже каскадная модель того, что происходит в вашем веб-приложении.
- Изучите основы Javascript в браузере.Попробуйте javascript в браузере без фреймворка, сначала изучите его основы, а затем выберите фреймворк, это поможет вам в долгосрочной перспективе и поможет понять, как работает фреймворк.
- Подумайте о SSR.Подумайте о рендеринге на стороне сервера с самого начала проекта. Я думаю, что ваши требования могут отличаться, но SSR дает много преимуществ, таких как более быстрая загрузка страницы, более быстрое время первого рендеринга, лучшая SEO и т. д. Angular предоставляет Angular Universal для SSR, у React есть разные методы, но наиболее распространенным является Next.js, который легко настраивается и предоставляет множество преимуществ из коробки, аналогично Next.js, Nuxt.js для Vue. Им нужна там отдельная статья.
- Используйте платформу —браузеры стали намного мощнее, чем раньше, например, появились веб-API для Push, Audio, Bluetooth, IndexeDB, Storage, WebGL и т. д.
- Используйте отложенную загрузку.Отложенная загрузка предоставляется всеми основными интерфейсными фреймворками, и даже вы можете реализовать ее с помощью ванильного javascript. Существуют руководства по ленивой загрузке, это ускорит рендеринг и загрузку вашей страницы.
Внешний интерфейс (мобильные приложения)
По мере того, как мобильные устройства набирали силу, люди начали переходить с нативных SDK на SDK на основе Javascript. Одной из основных причин является кроссплатформенная разработка с очень небольшим использованием собственного кода, а также вы можете использовать уже полученные знания о javascript для создания мобильных приложений. Несколько основных фреймворков: Ionic, React Native и Nativescript.
Я работал почти на всех трех по счастливой случайности. Кто-то для стартапа, а кто-то для фриланс-проектов.
React Native
Большинство вещей в React Native будут такими же, как и в React, поскольку логика компонентов одинакова и разделяется между ними. С моей стороны особо нечего рассказать о React Native, но есть одна вещь: научиться использовать такие вещи, как управление обновлением для разбиения на страницы, выбрать библиотеку маршрутизации и инфраструктуру пользовательского интерфейса, помня о будущем вашего проекта. Сначала просмотрите документацию, которая поможет вам во многом из того, что React Native предоставляет из коробки. Также недавний переход Google на androidx, попробуйте использовать новый React Native или обновить старый. React Native предоставляет руководство по обновлению.
У создания проекта React Native есть два пути — Expo или React Native CLI. Выберите один и начните свой проект, глядя на требования. Если вы начинаете с Expo, вы можете легко перейти на версию CLI, но наоборот — неверно. После выброса вы не можете вернуться на выставку. Итак, выбирайте с умом. Также многие библиотеки зависят от собственного кода, поэтому они могут не работать в Expo. Просмотрите документацию библиотеки, прежде чем использовать их.
Нативный скрипт
Подобно тому, что React Native делает для React, Nativescript делает для остальных фреймворков, таких как Angular, Vue, Svelte, React, или вообще без фреймворка. Angular — одна из зрелых платформ в Nativescript, а остальные — новые. Поэтому внимательно посмотрите на опору для отдыха, прежде чем двигаться вперед с одной.
ионный
Ionic предоставляет оболочку для вашего веб-приложения, чтобы сделать его доступным для установки в качестве собственного приложения на вашем телефоне. Он использует Cordova или недавно разработанную ionic команду Capacitor. Больше всего мне нравится в Capacitor то, что вы уже можете использовать огромную библиотеку плагинов Cordova в Capacitor (doc). Если ваше приложение не слишком большое и не нуждается в дополнительных функциях, которые предоставляют нативные приложения, лучше всего использовать Ionic. Раньше Ionic был основан на Angular, теперь они поддерживают все основные фреймворки, а не фреймворки, а все компоненты пользовательского интерфейса написаны в веб-компонентах, поэтому их можно использовать с любым фреймворком.
Это мои мысли о разработке с полным стеком и то, что я узнал из своего опыта. Также необходимо учитывать некоторые вещи, такие как развертывание, которым занимаются сами разработчики в стартапах. Существует множество вариантов между AWS, GCP, Azure, Openshift, Heroku и т. д. Для чего нужна отдельная статья.
Ссылки
