RTKQuery, как инструмент общения с API

На одном из проектов используем именно его. Плюсы:
- является частью Redux Toolkit — который мы уже используем для хранилища;
- поддержка React Native — хороший задел на будущее;
- генерация React hooks — буквально вчера вышел в релиз кодогенератор v1.0 см документацию (https://redux-toolkit.js.org/rtk-query/usage/code-generation);
- полная поддержка Typescript;
- отслеживание статуса запросов — плюс не нужно писать мидлвары для асинхронных запросов;
- возможность преобразования полученных ответов;
- встроенный кэш: по-умолчанию данные хранятся в памяти, пока на него существует подписка, например, при анмаунте компонента кэш очистится спустя минуту;
- система инвалидации кэша: мы можем связать различные эндпоинты между собой, чтобы при PATCH/POST запросе автоматически происходил refetch (например, постим в список — список обновляется);
- и многое другое.

Почитать обзорный материал можно тут: https://redux-toolkit.js.org/rtk-query/overview

#rdclr_frontend #React #product #read #library

Redux Toolkit createSlice — функция, которая помогает писать редьюсеры проще

Предлагаю взглянуть на демо крохотного приложения с использованием createSlice:
https://codesandbox.io/s/todo-list-logger-jwzwb?file=/src/index.tsx

Слева мы можем добавлять/удалять записи.
Справа отображается лог наших действий.

Вся логика реализована через 2 слайса:
contactsSlice https://codesandbox.io/s/todo-list-logger-jwzwb?file=/src/store/features/contactsSlice.ts
loggerSlice https://codesandbox.io/s/todo-list-logger-jwzwb?file=/src/store/features/loggerSlice.ts

Для создания слайса мы указываем название, начальное состояние и редьюсеры:

export const someSlice = createSlice({
  name,
  initialState,
  reducers,
});

Кроме того, мы можем указать extraReducers, что бы «ловить» действия от других слайсов. см. loggerSlice

Как вы могли заметить, при описании редьюсеров мы «мутируем состояние». Но на самом деле это не так.
Redux Toolkit использует под капотом Immer (https://immerjs.github.io/immer/).
Который в свою очередь отслеживает все мутации, а затем возвращает новое (не мутированное) состояние.

Например, вот редьюсер без Immer:

function handwrittenReducer(state, action) {
  return {
    ...state,
    first: {
      ...state.first,
      second: {
        ...state.first.second,
        [action.someId]: {
          ...state.first.second[action.someId],
          fourth: action.someValue
        }
      }
    }
  }
}

А вот с использованием Immer:

function reducerWithImmer(state, action) {
  state.first.second[action.someId].fourth = action.someValue
}

Как я и сказал, это позволяет писать редьюсеры проще.

Любые вопросы и критика приветствуется.
Как вы реализовали бы функцию отмены конкретного действия в логгере (см. демо)?

#rdclr_frontend #React #product #read #library #redux

Суть в том, что существует «старый добрый» способ описания хранилища состояний при помощи обычного react-redux.
Проблема старого способа в том, что приходилось писать очень много шаблонного кода (на жаргоне — бойлерплейта).
За это его постоянно ругали разработчики всех мастей.

Но затем вышел Redux Toolkit, который создан специально для решения данной проблемы.
Мы можем создавать все те же хранилища состояний, но при этом писать гораздо меньше кода, по сравнению с react-redux.

Однако реалии таковы, что это все же новый инструмент со своими нюансами, поэтому редко кто-то перепрыгивает
с react-redux на ReduxToolKit прямо на ходу.

#rdclr_frontend #React #product #read #library #redux

Генерация клиента из OpenAPI

Если ваш бэкенд использует Swagger (OpenApi 3.0) для генерации документации, то вы можете знатно упростить себе жизнь на крупном проекте.
Однако это упрощение идет дальше типичного чтения документации. Прямо сейчас вы можете генерировать Клиент, Сервер и Типы данных для TypeScript из файла openapi schema.

🎁 Пакет для генерации Клиента: https://github.com/OpenAPITools/openapi-generator-cli

Установка:
yarn add @openapitools/openapi-generator-cli
либо
npm install @openapitools/openapi-generator-cli

1️⃣ Предварительно создайте папку для результатов генерации и файл конфигурации.

2️⃣ После установки вам нужно создать файл конфигурации openapitools.json для генератора и папку для хранения результатов
openapitools.json:

{
 "$schema": "node_modules/@openapitools/openapi-generator-cli/config.schema.json",
 "spaces": 2,
 "generator-cli": {
  "version": "5.1.1",
  "generators": {
   "v1": {
    "generatorName": "typescript-fetch",
    "inputSpec": "link_or_path_to_yours_openapi_schema",
    "output": "path_to_yours_output",
    "additionalProperties": {
     "supportsES6": true,
     "sagasAndRecords": true,
     "typescriptThreePlus": true,
     "withInterfaces": true,
     "withoutRuntimeChecks": false
    }
   }
  }
 }
}


```3️⃣ Затем запустите процесс генерации командой:
```yarn openapi-generator-cli generate

4️⃣ В результате мы получим:
generated-api/models — здесь хранятся типы данных и функции для трансформации данных бэк->фронт фронт->бэк
generated-api/apis — здесь вы найдете сгрупированные по эндпоинтам классы для запросов к API

В идеале этого хватает для полноценного использования.
Однако, в случаях, когда ваш проект еще недостаточно стабилен, хорошая практика — использовать сгенерированный код, как референс.
Вы потратите меньше усилий на поддержке актуальности кода, т.к. проще сделать diff между двумя каталогами, чем вносить все изменения в модели вручную.

🦷 Если вам необходимы только типы для TypeScript, может подойти пакет: https://github.com/drwpow/openapi-typescript

Полный список генераторов вы найдёте здесь: https://openapi-generator.tech/docs/generators

#rdclr_frontend #React #product #read #library

Всем привет! Наступил декабрь, а это значит, что скоро Новый год. В преддверии этого праздника на просторах интернета часто появляются различные мини-игры, акции, забавные дудлы и тому подобное.

К счастью для нас, сфера разработки не исключение. Уже не первый год энтузиаст Eric Wastl разрабатывает адвент-календарь, суть которого в решении серии небольших программных головоломок различного уровня сложности. Каждый день, начиная с 1 декабря и заканчивая Новым годом, вам предоставляется новая задача, которую вы можете решить на вашем любимом языке программирования. Само собой начальные задачи не представляют какой-либо сложности и решаются довольно просто, но чем ближе 31 декабря, тем всё больше усилий от вас будет требовать этот мини-квест.

Предлагаю вам проверить свои силы и присоединиться к этому чиловому соревнованию!
Ссылка на календарь: https://adventofcode.com/

#read

АОП. Аспектно-ориентированное программирование

Всем привет! С вами снова Андрей, java-разработчик. Мы продолжим говорить об экосистеме java и смежных вещах. Сегодня затронем АОП. Тема очень обширная, поэтому в этой мини-статье заденем минимальные основы.

В рамках Spring-фреймворка АОП является некой сквозной логикой, которую мы можем использовать в любом месте приложения, всего навсего повесив аннотацию (или с помощью xml-разметки). Также этот механизм используется почти во всех модулях фреймворка Spring, являясь фундаментом для построения более сложных механизмов.

Пару недель назад мы уже краем касались этой темы, когда рассматривали self-inject’ы и Transactional-аннотацию. Под этой аннотацией, как и под многими другими, как раз таки и скрывается механизм аспектно-ориентированного программирования.

Зачем нам нужно АОП? Данный функционал хорошо себя показывает в задачах, связанных с логированием или предоставлением доступов к каким-либо ресурсам. Чтобы не дублировать код наших логов по всему проекту, мы можем вынести это в одно место и вызывать (с помощью аспектов) перед выполнением метода или после. В случае предоставления доступов бывают ситуации, когда нам нужно проверить доступ к ресурсам исходя не только из токена (или любого другого ключа) пользователя, а из данных, которые находятся, например, в базе данных. Есть ли у пользователя X доступ к скачиванию этой фотографии или архива с документами?

Давайте попробуем разобраться на простом примере (примеры будут сразу в следующих постах). Для начала, в pom.xml, вы должны иметь следующие зависимости: spring-boot-starter-web, spring-boot-starter-aop. Это минимальный набор, чтобы начать изучать spring aop. Рассмотрим самописные аспекты по логированию какой-то информации сигнатуре метода и по доступу к файлу.

#rdclr_backend #java

Аспект для логирования сигнатуры метода. Связан через аннотацию LogSomething (написана вручную, в ней нет ничего особенного)

#rdclr_backend #java

Аспект для логирования сигнатуры метода. Связан через аннотацию CheckFileAccess (написана вручную, в ней тоже нет ничего особенного)

#rdclr_backend #java

Сервис, где методы будут помечены созданными аннотациями LogSomething и CheckFileAccess

#rdclr_backend #java

Spring framework: под капотом

До этого мы с вами разбирали основные инструменты фреймворка Spring, которые помогают сделать нашу разработку проще.

Настало время разобраться, как же работает та самая «магия» Спринга под капотом. С помощью каких инструментов создаются бины, инжект бинов, что такое в принципе понятие Бин. Весь процесс от запуска приложения, до его окончательного рабочего состояния. И в этом нам поможет довольно известный разработчик Евгений Борисов, который в своих лекциях посвящает нас в работу движка фреймворка на самом низком уровне. Для качественной разработки эти знания просто необходимы, поэтому на собеседованиях java-разработчиков довольно часто попадаются вопросы этой тематики.

У Евгения на ютубе имеется целый цикл лекций по Спрингу на самые разные темы. Предлагаю вам начать изучение с одной из самых популярных из его лекций — Spring-потрошитель. Не пугайтесь, что видео 2014 года: оно актуально и по сей день, ибо под капотом фреймворк почти не изменился.

Часть 1 https://youtu.be/BmBr5diz8WA
Часть 2 https://youtu.be/cou_qomYLNU

#rdclr_backend #java #read

Java. Какую версию выбрать?

Начиная с 2017 года релизная политика версий java в корне поменялась. Вместо продолжительных застоев в несколько лет с накоплением большого количества фич, было принято решение перейти на релизы каждые полгода, выпуская маленькими партиями новый функционал. Если раньше можно было выбрать просто 8 версию, которая являлась LTS, и не прогадать с выбором, то теперь версий стало куда больше (на текущий момент уже 17). В связи с этим у многих новичков встает очевидный вопрос: как выбрать версию джавы? Может я просто возьму последнюю и все? Не совсем так, давайте разбираться.

Основным провайдером java является компания Oracle, которая предоставляет нам 2 типа jdk: OpenJdk и OracleJdk. Основное их отличие в том, что OracleJdk является платной и содержит в себе поддержку от самой компании (вы сможете им позвонить или написать письмо), если у вас возникнут какие-то проблемы. Такой вариант обычно необходим только очень большим продуктам и компаниям, поэтому мы его отбрасываем и будем пользоваться бесплатной версией. Скачать её можно тут – http://jdk.java.net

Теперь про версионность. Основной выбор всегда падает на LTS (Long Time Support) версии java, так как из-за долгой поддержки и исправления багов эти версии наиболее стабильны и преподносят меньшее число сюрпризов в продакшне. На текущий момент в мире все еще преобладает использование java 8, которая вышла в 2014 году. В основном это связано с тем, что на этой версии уже написаны крайне массивные продукты, которые потребуют больших трудозатрат и средств для переноса на более новые версии. А так как эти огромные продукты продолжают жить, то продолжает жить и java 8.

Для новых решений зачастую берется просто последняя LTS версия джавы. Да, вот так вот просто! До недавнего времени это была java 11, на текущий момент java 17. Но так как 17 версия все еще очень молодая (ей всего пару месяцев), я бы рекомендовал вам пока что выбрать 11 версию для изучения, так как не все еще основные инструменты и библиотеки успели переехать на новый релиз.

Также предлагаю вам посмотреть наикрутейшее выступление Тагира Валеева на JockerConf про то, как менялась java под капотом с 9 по 14 версию. https://youtu.be/5Y0Alqb9H_I

#rdclr_backend #java #read

Java. Какую версию выбрать? Часть 2

Помимо основного вендора java в лице Oracle, существуют и другие выпуски от других компаний. Давайте их рассмотрим:

🍒 1) AdoptOpenJDK
Проект, поддерживаемый сообществом. Команда выпускает билды, основанные на OpenJDK, отличие лишь в более долгосрочной поддержке. Команда занимается только билдами и не выпускает патчи для openjdk

🍩 2) Red Hat OpenJDK
Основана на версиях сборки OpenJDK, является коммерческим продуктом с платной поддержкой. В своих версиях компания нацелена на исправления безопасности в OpenJDK. В прошлом Red Hat отвечали за security-апдейты Java 6 и 7.

🫀 3) Azul Zulu
Основана на версиях OpenJDK, поставляется как open-source, но так же имеется — по сравнению с OracleJDK — более длительная коммерческая поддержка java 9, 13, 15.

🩱4) IBM JDK
Компании IBM требовалось написать свой собственный JIT-компилятор и свою собственную JVM, чтобы программы, написанные на java, могли запускаться на их мейнфреймах и при этом не заставлять разработчиков изучать новую java. Поэтому эти версии, с точки зрения программиста, практически идентичны.

🥡 5) Amazon Correto
Бесплатная версия сборки OpenJDK с долгосрочной поддержкой. Данная версия нацелена на максимальную производительность в облачных вычислениях. Так же Амазон каждый квартал выпускает багфиксы, что позволяет более оперативно устранять уязвимости.

🛺 6) Liberica JDK
Отечественная версия java, основанной также на OpenJDK. Плюсы перед OpenJDK все те же, что и других вендоров. Она бесплатна, более продолжительная коммерческая поддержка, частые выпуски обновлений безопасности, маленький размер контейнера (минимальный — всего 43.5мб).

Еще существенным плюсом является тот факт, что Liberica JDK Pro была внесена в реестр российского ПО. Это означает расширение диапазона применения Liberica JDK в государственных информационных системах, где крайне важна защита ПО от внешних факторов (например, санкций).

#rdclr_backend #java #read

Привет! Я Сережа, и я технический директор в Red Collar

На этой неделе я буду рассказывать о том, как мы строим разработку больших проектов. Но это будет завтра, а пока картинка в тему новостей об уязвимости последних пары недель

Каждую среду наша команда разработки тусит и слушает доклад на какую-нибудь интересную тему. Сегодня Марина рассказывает про информационную безопасность

Разбираем софт для командной разработки

Любой большой проект — это не только идея и код, который эту идею реализует. Проект — это команда, а команда — это постоянное общение и софт, помогающий быть на одной волне 🏄‍♂️

🧬Система контроля версий. Де-факто индустриальный стандарт — это Git, но можно встретить компании и проекты, которые используют Mercurial, SVN и более экзотические штуки. Чистый гит не очень удобен, поэтому фактически в разработке используют готовые системы управления репозиториями: gitlab, github, bitbucket.

📌 Вторая необходимая составляющая — трекер задач. Это место, где описываются и распределяются задачи, планируются спринты, отслеживается прогресс. Самое популярное решение здесь Jira, но есть и другие, например, youtrack или trello.

🗒 База знаний проекта — проектная вики, где документируются принятые решения, идеи, юзкейсы, архитектурные диаграммы. Из примеров — confluence, outline и, как ни странно, система README файлов.

🛠 CI/CD движки, собирающие из вашего кода докер образы, библиотеки, пакеты и разворачивающие их на окружениях. Jenkins, Teamcity, Gitlab pipelines, Bitbucket pipelines.

🎁 Хранилища артефактов. Npm, maven репозитории, регистры Docker образов. Из того, что первое приходит в голову — это Artefactory, Verdaccio, Nexus.

💣 Многие вендоры предлагают коробочные решения, объединяющие все или часть нужного функционала. Как правило, такие решения имеют очень хорошие интеграции: по каждой задаче можно увидеть все изменения кода, тесты, собранные артефакты, связанные документы. Это очень удобно для навигации и аналитики. Примеры — Atlassian Suite (Jira, Confluence, Bitbucket), Azure DevOps. Недавно появился еще один игрок — Jetbrains Space, который мы используем с лета в пилотном режиме на части проектов.

#rdclr_frontend #rdclr_backend #rdclr_QA

Мы узнали кучу всего интересного об

⚔️ OWASP
⚔️ Penetration тестирование
⚔️ OSINT
⚔️ Сколько стоит безопасность
⚔️ Как вырастить культуру безопасности в разработке софта

А вам интересно про это узнать? Скоро Рин будет дежурить по каналу и обо всем расскажет подробно ^_^

Для чего нужна система контроля версий?

🦕 Когда-то, давным-давно, программы писались в текстовых файлах и при командной разработке все изменения кода сливались вручную. И было это даже не в эру динозавров: еще в начале двухтысячных годов существовали проекты, где код объединяли с помощью diff разных директорий.

🔧 Но появлялись и наращивали функционал системы версионирования. В 1998 году в SVN появилась поддержка веток кода и их объединения, в 2005 году вышел всеми любимый Git.

🚀 Современные системы управления репозиториями не только хранят код, но и предоставляют платформу для код ревью, облачные редакторы, запускают сборки и делают многое другое.

🕸 Сейчас любой проект может иметь несколько репозиториев, а каждый репозиторий сотни веток кода. Все это дает огромную гибкость, но может превратиться в макаронный ад. В следующих постах мы расскажем, как этого избежать.

Но, прежде чем переходить к подробному разбору бестпрактисов, давайте проведем пару опросов.

#rdclr_backend #rdclr_frontend