что такое django rest framework

Кратко о Django Rest Framework

Что такое Django Rest Framework?

Django Rest Framework (DRF) — это библиотека, которая работает со стандартными моделями Django для создания гибкого и мощного API для проекта. Эта статья поможет понять структуру DRF и дать вводные данные для начала его использования

Основная архитектура

API DRF состоит из 3-х слоев: сериализатора, вида и маршрутизатора.

Сериализатор: преобразует информацию, хранящуюся в базе данных и определенную с помощью моделей Django, в формат, который легко и эффективно передается через API.

Вид (ViewSet): определяет функции (чтение, создание, обновление, удаление), которые будут доступны через API.

Маршрутизатор: определяет URL-адреса, которые будут предоставлять доступ к каждому виду.

Сериализаторы

Модели Django интуитивно представляют данные, хранящиеся в базе, но API должен передавать информацию в менее сложной структуре. Хотя данные будут представлены как экземпляры классов Model, их необходимо перевести в формат JSON для передачи через API.

Сериализатор DRF производит это преобразование. Когда пользователь передает информацию (например, создание нового экземпляра) через API, сериализатор берет данные, проверяет их и преобразует в нечто, что Django может сложить в экземпляр модели. Аналогичным образом, когда пользователь обращается к информации через API, соответствующие экземпляры передаются в сериализатор, который преобразовывает их в формат, который может быть легко передан пользователю как JSON.

Наиболее распространенной формой, которую принимает сериализатор DRF, является тот, который привязан непосредственно к модели Django:

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

Сериализаторы — это невероятно гибкий и мощный компонент DRF. Хотя подключение сериализатора к модели является наиболее распространенным, сериализаторы могут использоваться для создания любой структуры данных Python через API в соответствии с определенными параметрами.

Виды (ViewSets)

Каждая из этих функций может быть переопределена, если требуется другое поведение, но стандартная функциональность работает с минимальным кодом, а именно:

Если необходимы дополнительные настройки, можно использовать общие представления, вместо ModelViewSet или даже отдельные пользовательские представления.

Маршрутизаторы (роутеры)

И наконец, маршрутизаторы: они предоставляют верхний уровень API. Чтобы избежать создания бесконечных URL-адресов вида: «списки», «детали» и «изменить», маршрутизаторы DRF объединяют все URL-адреса, необходимые для данного вида в одну строку для каждого ViewSet, например:

Затем все ViewSet, которые зарегистрированны в маршрутизаторе, можно добавить к обычным url_patterns:

Теперь через API можно получить данные точно так же, как и любые другие обычные страницы Django.

Источник

Django Rest Framework для начинающих: создаём API для чтения данных (часть 1)

Меня зовут Стас Гаранжа, я выпускник курса «Python-разработчик» в Яндекс.Практикуме. Я хочу помочь начинающим разработчикам, которые приступили к изучению Django Rest Framework (DRF) и хотят разобраться, как устроен этот фреймворк.

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

В этой статье разберёмся, как сделать REST API на базе Django Rest Framework, чтобы получить по GET-запросу набор записей из базы данных (БД). Иными словами, рассмотрим, как DRF работает на чтение (о том, как с помощью него создавать, изменять и удалять записи в БД, поговорим в отдельной статье).

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

Несколько вводных замечаний:

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

API для сайта на Django: общая схема

Задача

На локальном сервере работает одностраничный сайт на Django. На единственной странице сайта по адресу http://localhost:8000 пользователи видят информацию о четырёх североевропейских столицах. Информация попадает на страницу из подключённой к сайту базы данных, в которой есть модель Capital с пятью полями:

Поле author через внешний ключ (foreign key) связано с моделью User, в которой есть вся информация о пользователе с конкретным id.

Мы хотим получить информацию из базы данных, не открывая сайт в браузере, а сделав запрос из другого Python-приложения.

В каком виде нужно получить информацию:

Таким образом, каждую запись, которая при извлечении из базы данных является Python-объектом, принимающее приложение после декодирования json-строки должно получать в виде словаря:

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

Решаем задачу с помощью Django Rest Framework

Задача решается в два шага:

Небольшое отступление о json. Базовые структуры данных на python кодируются в json и декодируются обратно следующим образом:

Создаём сериалайзер

Для сериалайзера нужно описать поля: каждое поле будет отвечать за извлечение и представление данных из корреспондирующего поля табличной записи.

Нас интересуют данные, которые есть в трёх полях каждой табличной записи:

Значит, в сериалайзере должно быть тоже три атрибута-поля.

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

Вот примеры трёх вариантов названий полей сериалайзера:

Очевидно, этот тип поля сериалайзера нельзя выбирать для данных из табличной записи о названии столицы: int(‘Осло’) вызовет ValueError. А вот для данных о численности населения — самое то.

Выберем следующие типы полей сериалайзера:

О соотношении полей сериалайзера и полей Django-моделей можно прочитать в документации DRF.

Код сериалайзера разместим в том же приложении, где находится Django-модель, под именем serializers.py:

Сериалайзер в действии

В serializer_example_1.py созданы классы с данными об авторах и о столицах для записей в таблицах:

Созданы объекты соответствующих записей:

Объединены записи в список по подобию кверисета из Django-модели:

Выведем в консоль содержимое атрибута data сериалайзера:

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

Отображаем (рендерим) информацию в формате json

Далее необходимо создать экземпляр рендера нужного типа и вызвать у него метод render :

В результате мы увидим байтовую строку с массивом json-объектов:

Что нужно ещё

Итак, мы испытали сериалайзер и посмотрели, как пропущенный через него набор табличных записей был преобразован в json-формат.

Чтобы сайт начал отдавать сериализованные данные, остаётся описать контроллер (view) и указать url-маршрут — эндпоинт, при обращении к которому сайт будет отдавать данные о столичных городах.

Контроллер

Во views.py создадим класс контроллера. Нам понадобятся следующие инструменты DRF:

Внутри контроллера описываем один метод — get. Почему он называется именно так?

Пример: если поступил GET-запрос, то будет задействован метод get контроллера.

В методе get опишем ту же логику, что и в файле с пробным запуском сериалайзера:

После того как отработал метод get, работа контроллера выглядит так:

Маршрут (эндпоинт)

Здесь та же схема действий, как в классическом Django. Подключаем маршруты приложения capitals:

Прописываем сам маршрут в приложении capitals и связываем маршрут с контроллером:

API в действии

Чтобы посмотреть, как работает API, можно:

Осталось выполнить шаги 2 и 3.

Если всё отработало штатно, в корневой директории проекта появится файл capitals.txt со следующим содержимым:

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

Browsable API — удобный инструмент для тестирования API на DRF

Django Rest Framework позволяет посмотреть в браузере, какую информацию будет отдавать API при обращении к конкретному маршруту (эндпоинту). Достаточно ввести маршрут в адресную строку, и откроется страница с данными о запросе и результате его выполнения. За такое отображение отвечает BrowsableAPIRenderer.

Итак, мы рассмотрели, как сделать API на базе DRF, чтобы получить по GET-запросу набор записей из Django-модели. Во второй части подробно разберём работу сериалайзера на чтение.
Если у вас появились вопросы по решению задачи, пишите в комментариях.

Источник

Создайте REST API за 30 минут с помощью Django REST Framework

Почему REST API?

Прежде чем мы перейдем к коду, стоит подумать, зачем вам создавать API. Если бы кто-нибудь объяснил мне эти основные концепции до того, как я начал, мне было бы намного лучше.

Есть несколько ключевых вариантов запроса REST API:

Например, в веб-разработке многие приложения полагаются на REST API, чтобы интерфейсная часть могла взаимодействовать с серверной частью. Например, если вы развертываете приложение React поверх Django, вам понадобится API, чтобы React мог получать информацию из базы данных.

Процесс запроса и преобразования значений табличной базы данных в JSON или другой формат называется сериализацией. При создании API правильная сериализация данных является основной проблемой.

Почему Django REST Framework?

Самая большая причина использовать Django REST Framework заключается в том, что он упрощает сериализацию!

В Django вы определяете свои модели для своей базы данных с помощью Python. Хотя вы можете писать необработанный SQL, по большей части Django ORM обрабатывает все миграции и запросы базы данных.

Думайте о Django ORM как о библиотекаре, который собирает необходимую вам информацию, чтобы вам не приходилось искать ее самостоятельно.

Как разработчик, вы можете не беспокоиться о бизнес-логике вашего приложения и забыть о деталях реализации на низком уровне. Django ORM сделает все за вас.

Таким образом, Django REST Framework прекрасно работает с Django ORM, который уже выполняет всю тяжелую работу по запросам к базе данных. Всего несколько строк кода с использованием Django REST Framework, и вы можете сериализовать свои модели баз данных в форматы REST-ful.

Список пунктов для создания REST API в Django

Итак, исходя из того, что мы знаем, каковы шаги по созданию REST API?

Если это кажется простым, это потому, что это так. Поехали!

1. Настройка Django

Чтобы создать приложение Django, нам нужно установить Django. Это достаточно просто!

Однако сначала рассмотрите возможность создания новой виртуальной среды для вашего проекта, чтобы вы могли управлять своими зависимостями отдельно.

Вот видео этих шагов (но с другим названием проекта), если вы визуально обучаетесь: Видеурок «Создание Django приложения», Начинаем Django приложение правильно

1.1 Virtual Environment

Я использую pyenv и pyenv-virtualenv для своих сред:

1.2 Установка Django

Теперь мы можем установить Django:

Затем давайте начнем новый проект Django:

Если мы сейчас посмотрим на каталог, то увидим, что Django создал для нас новую папку:

И если мы заглянем в эту папку, там есть все, что нам нужно для запуска сайта Django:

Давай убедимся, что это работает. Тестовый запуск сервера Django:

1.3 Создание приложения API

Мы могли бы создать наше приложение со структурой папок, как сейчас. Однако лучше всего разделить проект Django на отдельные приложения, когда вы создаете что-то новое.

Итак, давайте создадим новое приложение для нашего API:

1.4 Зарегистрируйте приложение myapi в проекте mysite

Нам нужно сказать Django, чтобы он распознал это новое приложение, которое мы только что создали. Шаги, которые мы сделаем позже, не сработают, если Django не знает о myapi.

Итак, редактируем mysite/settings.py :

1.5 Перенести базу данных

Помните, как я сказал, что Django позволяет определять модели баз данных с помощью Python?

Каждый раз, когда мы создаем или вносим изменения в модель, нам нужно указать Django перенести эти изменения в базу данных. Затем Django ORM записывает для нас все команды SQL CREATE TABLE.

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

Итак, давайте перенесем эти исходные модели:

1.6 Создать суперпользователя

Еще одна вещь, прежде чем мы продолжим.

Мы собираемся создать несколько моделей. Было бы неплохо, если бы у нас был доступ к красивому интерфейсу администратора Django, когда мы хотим просматривать данные в нашей базе данных.

Для этого нам потребуются учетные данные для входа. Итак, давайте сделаем себя владельцами и администраторами этого проекта. ВСЕМОГУЩЕГО СУПЕРПОЛЬЗОВАТЕЛЯ.

Убедимся, что это работает. Запустите сервер Django:

А затем перейдите на localhost:8000/admin

Войдите в систему со своими учетными данными суперпользователя, и вы должны увидеть панель администратора:

2. Создайте модель в базе данных, которой будет управлять Django ORM.

Сделаем нашу первую модель!

2.1 myapi/models.py

Создадим базу супергероев! У каждого героя есть имя и псевдоним, которым они пользуются в обычной жизни. Начнем с нашей модели:

2.2 Сделайте миграции

Помните, что всякий раз, когда мы определяем или изменяем модель, нам нужно указать Django перенести эти изменения.

2.3 Зарегистрируйте Hero на сайте администратора

Помните тот замечательный админский сайт, который поставляется прямо из коробки с Django?

Откройте myapi/admin.py и сделайте так:

Теперь запустим сервер Django:

2.4 Создайте новых героев

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

Нажмите «Добавить» и создайте своих героев!

3. Настройте Django REST Framework.

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

Для этого нам понадобится Django REST Framework, так что давайте установим его.

Теперь скажите Django, что мы установили REST Framework в mysite/settings.py :

4. Сериализация модели героя

Теперь мы начинаем открывать новые горизонты. Нам нужно сообщить REST Framework о нашей модели Hero и о том, как она должна сериализовать данные.

В этом файле нам необходимо:

5. Отображение данных

Теперь все, что осталось сделать, это подключить URL-адреса и представления для отображения данных!

5.1 Представления

Начнем с представления. Нам нужно отрендерить разных героев в формате JSON.

Для этого нам необходимо:

5.2 URL-адреса

Вы увидите, что URL-адрес сайта администратора уже присутствует. Теперь нам просто нужно добавить URL-адрес для нашего API. А пока давайте просто поместим наш API в индекс:

5.3 URL для API

Маршрутизатор REST Framework будет следить за тем, чтобы наши запросы динамически попадали в нужный ресурс. Если мы добавим или удалим элементы из базы данных, URL-адреса обновятся, чтобы соответствовать. Круто, правда?

Конечно, если вы хотите использовать только стандартные представления DRF вместо наборов представлений, urls.py будет выглядеть немного иначе. Для использования простых представлений маршрутизатор не нужен, их можно просто добавить с помощью:

Проверьте!

Снова запустите сервер Django:

Теперь перейдите на localhost:8000

Посетите конечную точку через GET

GET для индивидуального героя

Мы можем запросить с помощью GET единственный экземпляр модели, используя его ID.

viewsets представлений Django REST Framework позаботятся об этом за нас.

Например, http://127.0.0.1:8000/heroes/1/ для меня возвращает:

Теперь список героев выглядит так:

Мы можем использовать эти идентификаторы для поиска отдельных моделей.

Отправить запрос POST

Наш API также обрабатывает POST запросы. Мы можем отправить JSON в API, и он создаст новую запись в базе данных.

Теперь в нашем API есть Капитан Америка!

Быстрые API REST с Django REST Framework

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

Тем не менее, вы хорошо продвигаетесь с этим постом. REST Framework довольно хорошо справляется со сложностью. Если вы застряли, есть отличное сообщество, готовое помочь вам найти решение.

Источник

Что такое Django REST Framework?

Я написал эту статью, чтобы рассказать в ней теорию, которая будет необходима для изучения Django REST Framework. Информация, изложенная в этой статье, не является исчерпывающей в данной теме и показывает историю развития веб-приложений лишь отчасти. Я просто постараюсь объяснить, почему этот фреймворк — часть естественной эволюции веб-технологий, и как при помощи него мы можем по-новому решать старые задачи веб-разработки.

Чтобы ответить на вопрос, что же такое Django REST Framework, нужно разобраться со всей необходимой терминологией.

Framework

Создавая приложение или любой другой программный продукт, мы хотим делать это быстро и качественно. Проще этого добиться, используя опыт и наработки других разработчиков, ведь многие задачи, которые мы встречаем в процессе работы, уже были кем-то решены. По сути, использование фреймворка позволяет сосредоточится на задачах бизнеса и не задумываться над техническими деталями там, где это возможно. Нужно отрисовать кнопку на сайте? Сделать авторизацию или сброс пароля? Сохранить данные пользователя из формы на сайте в базу данных? Для этого всё уже готово — бери и пользуйся!

Также важно понимать отличия Framework от библиотеки. Это похожие вещи. В обоих случаях в Python вы должны установить нужный пакет, импортировать и пользоваться им. Разница в том, что библиотеку в проекте вы используете там, где нужно, и так, как вы хотите, а фреймворк сам определяет способ разработки приложения, то есть не только предоставляет удобные инструменты разработки в виде вспомогательных функций и классов, но и непосредственно формирует архитектуру проекта, создает структуру кода, проще говоря, определяет путь, по которому вы будете создавать свое приложение.

Django

На сегодняшний день наиболее функциональным фреймворком для создания веб-приложений на языке Python является фреймворк Django. Django можно назвать MVC-фреймворком, так он реализует взаимодействие пользователя и системы:

Model (хранит данные пользователя)

View (отображает данные пользователя)

Controller (принимает изменения данных от пользователя).

Внутри Django эта терминология звучит немного иначе, но суть остается той же.

Разработка Django началась в 2003 году программистами Adrian Holovaty и Simon Willison, а публичный релиз состоялся в 2005 году. Функционал фреймворка хорошо отвечал требованиям в веб-разработке того времени. Он активно развивается и до сих пор. Хотя этот фреймворк и считается довольно крупным и многофункциональным, сам по себе он не мог удовлетворить все запросы веб-разработчиков. За время его существования сторонними разработчиками было создано огромное множество библиотек и фреймворков в качестве дополнений к Django, которые упрощают реализацию тех или иных задач: аутентификация через социальные сети, кеширование данных, хранение файлов в облаке и многое другое. Некоторые из дополнений со временем сами стали частью проекта Django, как это произошло с библиотекой South, управляющей миграциями базы данных. Но большинство дополнений так и остались независимыми пакетами. Одним из них и является Django REST Framework, при помощи которого мы можем создавать Web API на основе Django.

Web API

Сегодня сеть интернет построена по принципу Клиент-Серверного взаимодействия. Клиент посылает запрос — Сервер ему отвечает. В случае, когда между собой общаются два Сервера, мы условно называем Клиентом того, который отправил запрос и ожидает ответ, а Сервером будет тот, кто принимает запрос и отвечает не него. Взаимодействие браузеров и веб-сайтов (первые выступают в роли Клиента, а вторые в роли Сервера) традиционно делалось при помощи технологии html-рендеринга, именно так изначально это делал Django. Чтобы получить данные с веб-сайта, браузер отправляет запрос GET к Серверу. Сервер формирует ответ в виде html-страницы и передает ее браузеру. Так Сервер передает данные браузеру, но как браузер может передать данные Серверу? В этой самой html-странице Сервер заложил все необходимые веб-формы, заполнив которые, пользователь мог бы передать свои данные обратно на сервер. Когда вы ввели свои данные в форму на сайте, бразуер отправляет Серверу запрос POST, в котором содержатся ваши данные, а Сервер обрабатывает их и записывает в базу данных.

Все это отлично работало, но уже в середине нулевых такой подход перестал удовлетворять возрастающим требования в веб-разработке. Появлялись мобильные приложения, различные гаджеты с доступом в интернет, и для них уже не подходил стандартный способ html-рендеринга на сервере, ведь теперь каждому клиенту нужно было отрисовать данные по-своему. Постоянно увеличивалось взаимодействие серверов друг с другом, и html-формат уже не подходил. Для всех этих задач есть другой способ обмена данными — Web API. Смысл этого способа в том, что Сервер передает Клиенту не html-страницу, а непосредственно данные, никак не влияя на то, как эти данные будут в итоге представлены. Наиболее популярными форматами для передачи данных становятся XML и JSON. Таким образом Сервер полностью избавляется от задачи отрисовки данных. Какое-то время длился переходный период, когда разработчикам веб-приложений на Сервере приходилось поддерживать оба способа одновременно: html рендерился на Сервере для браузеров, а Web API использовался для мобильных приложений и интеграции с другими серверами. Понятно, что разработчикам приложений на Сервере приходилось делать двойную работу. Но в начале десятых ситуация стала меняться в пользу Web API. Этому способствовало молниеносное развитие инструментов на языке JavaScript, а также появление различных веб-фреймворков, одним из которых и является предмет данной статьи.

Браузерные приложения быстро научились отрисовывать веб-страницы самостоятельно, получая чистые данные с Сервера. Веб-приложения на сервере научились создавать API быстро и легко. Так сформировалась четкое разделение на Backend и Frontend разработку: тех, кто поддерживает приложение на Сервере, и тех, кто делает браузерные (клиентские) приложения. А Web API стал универсальным способом общения для Сервера и всех его клиентов (браузеров, мобильных приложений, других Серверов). Конечно, это не могло не привести к развитию стандартов в общении между системами. И Клиенту, и Серверу необходимо знать каким образом общаться с друг с другом, как передавать данные, как сообщать об ошибках. Разработчики всегда могли договориться о том, как взаимодействовать их приложениям, но наличие некоего стандарта в веб-разработке позволило бы эту задачу облегчить. И вот в начале десятых таким стандартом стала концепция REST.

В 2000 году Рой Филдинг написал докторскую диссертацию, где изложил концепцию REST. Там были рекомендации о том, как спроектировать Сервер, чтобы ему было удобно общаться с Клиентами. Выделю два главных принципа создания приложений в стиле REST:

На данный момент мы можем найти фреймворк для создания приложений в стиле REST практически для каждого языка программирования, используемого в веб-разработке. Логика построения Web API на Сервере в этих фреймворках реализована одинаково.

Действия для управления данными привязаны к определенным HTTP-методам. Существует несколько стандартных действий для работы с данными — это Create, Read, Update, Delete. Часто их обобщают как CRUD.

У нас есть объект Кошка, и мы хотим создать запись о кошке на Сервере. Для этого мы отправляем запрос на сервер:

С данными в теле запроса

Плюс к этому запросу (и все другим) будет добавлен ключ аутентификации.

Ключ будет нужен, чтобы Сервер понял, что запрос происходит от авторизованного Клиента. Как мы помним из правила REST, каждый запрос от Клиента должен содержать всю необходимую информацию для обработки этого запроса Сервером. Здесь это правило работает: Сервер ничего не знает о Клиенте до запроса, но сам запрос содержит ключ авторизации, по которому Сервер определяет, что это за Клиент.

Сервер ответит на этот запрос вот таким сообщением:

Сервер взял все поля, переданные клиентом, и добавил к ним поле Id. Здесь работает правило REST, согласно которому каждый ресурс должен иметь уникальный идентификатор и быть доступным по определенному URL. Сервер создал ресурс и вернул нам его Id.

Теперь мы можем получить данную запись по URL

Что, если Клиент хочет изменить созданные им данные на сервере?

Метод PUT используется для изменения данных. Номер 21 в URL говорит о том, какой именно объект нужно изменить. Теперь наша кошка имеет цвет “Black”.

Для удаления записи на Сервере достаточно отправить запрос:

Тут также мы указываем в Id объекта в URL, но передавать никаких данных в теле запроса для удаления объекта уже не требуется.

Django REST Framework

Наконец, мы добрались до главной темы этой статьи. Мы вкратце разобрали каждый компонент этого словосочетания и теперь сможем понять, зачем использовать этот фреймворк, и какие задачи он решает.

Тут я бы хотел процитировать слова Тома Кристи, создателя Django REST Framework.

“Неудивительно, что Django REST framework — это API фреймворк для Django. И он пытается заполнить все пробелы в том, как исторически был спроектирован веб-фреймворк Django”.

И действительно, пусть Django был спроектирован давно, он до сих отлично решает свои задачи. Однако с появлением новых требований в веб-разработке, отсутствие компонентов для создания Web API воспринимается как пробел.

Django REST framework способен этот пробел заполнить.

А мы уже заполнили все пробелы в теории и терминологии и готовы перейти к практике!

Мы рассказываем, как стать более лучшим разработчиком, как поддерживать и эффективно применять свои навыки. Информация о вакансиях и акциях эксклюзивно для более чем 8000 подписчиков. Присоединяйся!

Источник