Как взаимодействуют frontend и backend ?

Ассаляму алейкум

(Подсмотрел статью у коллег. Отличный материал, ссылка на источник в конце.)

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

Архитектура взаимодействия

Фронтенд: Это часть веб-приложения, с которой взаимодействует пользователь. Она включает HTML, CSS и JavaScript, а также фреймворки и библиотеки, такие как React, Vue.js и Angular. Фронтенд отвечает за отображение данных, обработку событий и обеспечение интерактивности.

Бэкенд: Это серверная часть веб-приложения, которая управляет бизнес-логикой, обработкой данных и взаимодействием с базой данных. Бэкенд может быть написан на разных языках программирования, таких как C#, Python, Ruby, Java, PHP и других. Он включает веб-серверы, базы данных и API.

HTTP-запросы и ответы
Фронтенд и бэкенд взаимодействуют через HTTP-запросы и ответы. Фронтенд отправляет запросы на сервер (бэкенд), который обрабатывает их и отправляет ответы обратно на фронтенд.

Запрос данных:
- Фронтенд отправляет HTTP GET-запрос на сервер, чтобы получить данные.
- Бэкенд получает запрос, извлекает данные из базы данных и отправляет их обратно в виде JSON-ответа.

// Фронтенд (JavaScript с использованием Fetch API)
fetch('https://api.example.com/data')
  .then(response => response.json())
  .then(data => {
    console.log(data); // Обработка данных на фронтенде
  })
  .catch(error => {
    console.error('Error:', error);
  });

Отправка данных:
- Фронтенд отправляет HTTP POST-запрос на сервер с данными для создания нового ресурса.
- Бэкенд получает запрос, обрабатывает данные и сохраняет их в базе данных, затем отправляет ответ о статусе операции.

// Фронтенд (JavaScript с использованием Fetch API)
fetch('https://api.example.com/data', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ key: 'value' })
})
  .then(response => response.json())
  .then(data => {
    console.log(data); // Обработка ответа на фронтенде
  })
  .catch(error => {
    console.error('Error:', error);
  });

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

// Фронтенд (JavaScript с использованием WebSocket API)
const socket = new WebSocket('ws://example.com/socket');

socket.onopen = () => {
  console.log('WebSocket is open now.');
  socket.send(JSON.stringify({ message: 'Hello Server!' }));
};

socket.onmessage = (event) => {
  console.log('Received:', event.data);
};

socket.onclose = () => {
  console.log('WebSocket is closed now.');
};

RESTful API и GraphQL

RESTful API: Это стиль архитектуры API, который использует стандартные HTTP методы (GET, POST, PUT, DELETE) для взаимодействия с ресурсами. Каждый ресурс идентифицируется уникальным URL, а данные передаются в формате JSON или XML.

GraphQL: Это язык запросов для API, который позволяет клиенту запрашивать именно те данные, которые ему нужны. В отличие от REST, где каждый ресурс имеет свой URL, в GraphQL есть единая точка доступа (endpoint), и запросы могут быть более гибкими и оптимизированными.

👉 @seniorFront

Почему CTO не играет в прятки?

Потому что даже если он спрячется, его все равно видно в стеклянном офисе микроменеджмента 😄

#Шуткипонедельника

*⚡️ ТЕХНИЧЕСКИЙ ДОЛГ: КОГДА СОКРОВИЩА ПРЕВРАЩАЕТСЯ В ПРОБЛЕМУ (И КАК НЕ СТАТЬ ПИРАТОМ-БАНКРОТОМ) ⚡️*

Представьте: вы — капитан корабля, который нашёл сундук с золотом (ура!). Но через месяц понимаете, что это не золото, а килограммы ржавых гвоздей (ой). Вот так и техдолг — сначала «быстро починим», а потом «почему всё сломалось?».

Как отличить сокровище от гвоздей?
1. Если ваш «фикс» живет дольше, чем офисный кактус — это уже техдолг. 🌵
2. Если при упоминании кода у команды начинается тик — это техдолг. 😬
3. Если на рефакторинг нужно больше времени, чем на полёт до Марса — это... вы поняли. 🚀

Диалог моих двух «Я»:
- Senior Dev: «Да ладно, этот костыль выдержит ещё пару месяцев!»
- Future CTO: «Месяца? Ты уверен, что он выдержит *завтрашний деплой*?»

Совет 🏴‍☠️:
«Техдолг — как незваный гость. Если не выгнать сразу, он съест весь твой пирог (и заляжет на диване в продакшене)».

*📌 Ваше задание:*
👉 Напишите в комментах, как вы «договариваетесь» с техдолгом:
- Вариант А: Рефакторить ночью, пока кофе не закончился.
- Вариант Б: Притвориться, что это фича.
- Вариант В: Написать «TODO» и бежать в бункер.

*«Лучший способ понять, что ваш код слишком сложный — это попытаться объяснить его коллеге. Если после пяти минут объяснений он смотрит на вас, как на человека, который только что рассказал, как построить ракету из палок и скотча, — возможно, пора рефакторить.»*

#Шуткипонедельника

Ассаляму алейкум

Тема рефакторинга. А точнее, как понять что пора?

Вот пришёл ты на проект, начинаешь вникать и понимаешь, что нет общих концепций. Есть разрозненные куски общих паттернов, различные бест практисес смежных библиотек и куча куча костылей.

Всё! Круто! Настало твоё время!

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

Поздравляю вас, так есть!

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

Чё делать?

В рабочее время фигачить бизнес задачи в свободное время приводить код в порядок и улучшать перформанс.

Отличное решение! Здравствуй выгорание через полтора месяца.

Такая ситуация даёт возможность прокачать софт скилы разработчика. Мы же хотим стать СТО.

Ну начнем с идеи. Да, идеи. Эту идею нужно понять, зацепить ею коллег и продать бизнесу.
Ну как вам, чувствуете в себе Наполеона?

...

Так идея.

Ассаляму алейкум

Чем отличается канал реального разработчика от инфо-гуру разработки?

У реального разработчика статьи выходят редко 😏

Вот подписан я на одного оч крутого фронтендера с Яндекса, Семён его зовут.

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

Почему так получается?

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

О чём я?

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

Если интересна эта тема, расскажу как я получал этот опыт рядом с крутым тех лидом, около 5 лет назад.

Ассаляму алейкум

Rust or Go

На днях произошёл спор с разработчиками и техлидом.
Обсуждали языки Go и Rust.
Основной код на наших сервисах написан на nodejs, также есть немного python, java и малость Rust.

У меня есть опыт работы с Go и я с уверенностью говорю что это простой язык. На нём просто писать бизнес логику и код достаточно долго остаётся понятным.

Это очень удобно, когда работаешь в команде.

Всё познаётся в сравнении.
Возьмём к примеру питон. Стоит немного отойти от шаблонов Джанго или погрузиться в ML как код становиться не читаемым.

Что касается Rust, с ним я не работал, только познакомился.
Мне он показался достаточно сложным и многословным.

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

Основные аргументы техлида это Rust быстрый, Rust безопасный, бигтехи поторопились что перешли на Go и сейчас жалеют.

На каждый тезис у меня вопросы. И мне стало очень любопытно, а ведь может Rust не такой сложный.

Решение!
Нужен петпроект, примерно на пол года. За это время я смогу прощупать язык и инструментарий.

Чтобы нормально испытать язык, хорошим решением будет сделать трейдинг бот.
Какие фичи я на нем испробую:
- Основной функционал языка;
- Асинхронную работу;
- Многопоточность;
- Работу с API, json, различными протоколами;
- Удобство добавления новых фич;
- Полиморфизм, работу с дженериками;
- удобство работы с модулями;
- Также прощупаю безопасность, постреляю себе в ноги)) а как иначе?

Постараюсь отписываться сюда об интересных моментах.