Java for Beginner
Вы еще читаете этот канал?
Реально странно...
Из 750 человек на канале только 33 вообще отреагировало на пост, и только 20 читает канал постоянно...(((
А зачем остальные подписались? Боты? Вроде все живые люди))))
Как мне оживить канал, подскажите?
Из 750 человек на канале только 33 вообще отреагировало на пост, и только 20 читает канал постоянно...(((
А зачем остальные подписались? Боты? Вроде все живые люди))))
Как мне оживить канал, подскажите?
История IT-технологий сегодня — 11 ноября
ℹ️ Кто родился в этот день
Гевин Андресен (англ. Gavin Andresen, имя при рождении Гевин Белл, англ. Gavin Bell) — программист, ключевая фигура ранней разработки программного обеспечения для Bitcoin; после ухода Сатоши Нового он был фактическим ведущим разработчиком референсной реализации клиента.
🌐 Знаковые события
1572 — датский астроном Тихо Браге обнаруживает вспышку сверхновой звезды в созвездии Кассиопеи.
1983 — калифорнийский студент Фред Коэн успешно завершил курсовую работу по созданию прототипа первого компьютерного вируса — программы, которая была способна к саморазмножению и распространению по сетям.
#Biography #Birth_Date #Events #11Ноября
Гевин Андресен (англ. Gavin Andresen, имя при рождении Гевин Белл, англ. Gavin Bell) — программист, ключевая фигура ранней разработки программного обеспечения для Bitcoin; после ухода Сатоши Нового он был фактическим ведущим разработчиком референсной реализации клиента.
1572 — датский астроном Тихо Браге обнаруживает вспышку сверхновой звезды в созвездии Кассиопеи.
1983 — калифорнийский студент Фред Коэн успешно завершил курсовую работу по созданию прототипа первого компьютерного вируса — программы, которая была способна к саморазмножению и распространению по сетям.
#Biography #Birth_Date #Events #11Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1
Что такое GraphQL и зачем он появился
Почему REST перестал устраивать и как Facebook придумал альтернативу
Современные приложения всё чаще строятся вокруг API.
Клиентам — будь то браузеры, мобильные приложения или IoT-устройства — нужны данные с сервера.
Долгое время стандартом для этого был REST, но со временем его ограничения стали очевидны.
Именно в ответ на эти ограничения в 2012 году в Facebook родился GraphQL — язык запросов для API, который изменил способ взаимодействия клиента и сервера.
1. Почему REST перестал всем подходить
REST долгое время считался идеальным способом построения API: простые URL, понятные методы (GET, POST, PUT, DELETE), формат JSON, читаемость.
Но со временем приложения стали сложнее, особенно на фронтенде.
Проблема 1: избыточные данные (overfetching).
REST-эндпоинт /users/42 возвращает всю информацию о пользователе — даже если на экране нужно только имя и аватар.
Клиент не может сказать серверу: “дай только эти два поля”.
В итоге трафик растёт, запросы замедляются, особенно на мобильных устройствах.
Проблема 2: недостаток данных (underfetching).
Обратная ситуация — когда данных не хватает.
Например, чтобы показать пользователя вместе с его постами и комментариями, REST-клиенту придётся сделать три запроса: /users/42, /users/42/posts, /posts/{id}/comments.
Каждый запрос — это отдельное соединение, время, накладные расходы.
Проблема 3: разные клиенты — разные потребности.
Мобильное приложение хочет меньше данных (экономия трафика), веб-клиент — больше.
REST вынуждает сервер создавать несколько версий эндпоинтов:
/users, /users/details, /users/short, и всё это быстро превращается в хаос.
Проблема 4: сложная эволюция.
Добавление новых полей или изменение структуры часто ломает старых клиентов.
Нужны версии: /v1/users, /v2/users, /v3/users.
С ростом проекта версионность превращается в отдельную боль.
Все эти проблемы — прямое следствие того, что REST навязывает структуру данных с серверной стороны.
Клиент получает то, что сервер решил вернуть.
GraphQL переворачивает это с ног на голову.
2. История появления GraphQL
GraphQL был создан внутри Facebook в 2012 году, когда компания столкнулась с резким ростом мобильных клиентов.
REST больше не справлялся: каждое обновление приложения требовало всё больше запросов к серверу, а мобильный интернет не прощал лишних килобайт.
Команда Facebook решила, что сервер не должен диктовать, какие данные возвращать.
Вместо этого клиент должен описывать свои потребности декларативно — “мне нужны вот такие данные, вот в такой структуре”.
В 2015 году Facebook открыл исходный код GraphQL, и он быстро стал стандартом в индустрии.
Сегодня его используют GitHub, Shopify, Twitter, Netflix, Pinterest, Airbnb и тысячи других компаний.
3. Основная идея GraphQL
Главная концепция GraphQL проста, но революционна:
клиент сам определяет, какие данные ему нужны.
Клиент не делает серию запросов к разным ресурсам, как в REST.
Он отправляет один запрос на сервер с точным описанием нужных полей, а сервер возвращает данные в том же формате.
Пример запроса:
Ответ сервера:
Клиент получает ровно то, что запросил — ни байта больше, ни меньше.
Больше нет проблемы overfetching или underfetching.
#Java #middle #GraphQL
Почему REST перестал устраивать и как Facebook придумал альтернативу
Современные приложения всё чаще строятся вокруг API.
Клиентам — будь то браузеры, мобильные приложения или IoT-устройства — нужны данные с сервера.
Долгое время стандартом для этого был REST, но со временем его ограничения стали очевидны.
Именно в ответ на эти ограничения в 2012 году в Facebook родился GraphQL — язык запросов для API, который изменил способ взаимодействия клиента и сервера.
1. Почему REST перестал всем подходить
REST долгое время считался идеальным способом построения API: простые URL, понятные методы (GET, POST, PUT, DELETE), формат JSON, читаемость.
Но со временем приложения стали сложнее, особенно на фронтенде.
Проблема 1: избыточные данные (overfetching).
REST-эндпоинт /users/42 возвращает всю информацию о пользователе — даже если на экране нужно только имя и аватар.
Клиент не может сказать серверу: “дай только эти два поля”.
В итоге трафик растёт, запросы замедляются, особенно на мобильных устройствах.
Проблема 2: недостаток данных (underfetching).
Обратная ситуация — когда данных не хватает.
Например, чтобы показать пользователя вместе с его постами и комментариями, REST-клиенту придётся сделать три запроса: /users/42, /users/42/posts, /posts/{id}/comments.
Каждый запрос — это отдельное соединение, время, накладные расходы.
Проблема 3: разные клиенты — разные потребности.
Мобильное приложение хочет меньше данных (экономия трафика), веб-клиент — больше.
REST вынуждает сервер создавать несколько версий эндпоинтов:
/users, /users/details, /users/short, и всё это быстро превращается в хаос.
Проблема 4: сложная эволюция.
Добавление новых полей или изменение структуры часто ломает старых клиентов.
Нужны версии: /v1/users, /v2/users, /v3/users.
С ростом проекта версионность превращается в отдельную боль.
Все эти проблемы — прямое следствие того, что REST навязывает структуру данных с серверной стороны.
Клиент получает то, что сервер решил вернуть.
GraphQL переворачивает это с ног на голову.
2. История появления GraphQL
GraphQL был создан внутри Facebook в 2012 году, когда компания столкнулась с резким ростом мобильных клиентов.
REST больше не справлялся: каждое обновление приложения требовало всё больше запросов к серверу, а мобильный интернет не прощал лишних килобайт.
Команда Facebook решила, что сервер не должен диктовать, какие данные возвращать.
Вместо этого клиент должен описывать свои потребности декларативно — “мне нужны вот такие данные, вот в такой структуре”.
В 2015 году Facebook открыл исходный код GraphQL, и он быстро стал стандартом в индустрии.
Сегодня его используют GitHub, Shopify, Twitter, Netflix, Pinterest, Airbnb и тысячи других компаний.
3. Основная идея GraphQL
Главная концепция GraphQL проста, но революционна:
клиент сам определяет, какие данные ему нужны.
Клиент не делает серию запросов к разным ресурсам, как в REST.
Он отправляет один запрос на сервер с точным описанием нужных полей, а сервер возвращает данные в том же формате.
Пример запроса:
query {
user(id: 42) {
name
avatar
posts(limit: 3) {
title
likes
}
}
}Ответ сервера:
{
"data": {
"user": {
"name": "Den",
"avatar": "https://example.com/den.jpg",
"posts": [
{ "title": "gRPC и Java", "likes": 120 },
{ "title": "GraphQL под капотом", "likes": 80 },
{ "title": "Spring Boot и микросервисы", "likes": 95 }
]
}
}
}Клиент получает ровно то, что запросил — ни байта больше, ни меньше.
Больше нет проблемы overfetching или underfetching.
#Java #middle #GraphQL
👍1
4. Как это работает
В GraphQL всё держится на схеме (schema).
Она описывает, какие типы данных доступны, какие поля у них есть и какие операции разрешены.
Пример схемы:
GraphQL строго типизирован.
Клиент знает, какие поля доступны и какого они типа, а сервер может валидировать запрос до его выполнения.
5. Ключевые преимущества GraphQL
1. Гибкость запросов
Клиент формирует запрос под себя:
на мобильном — только name и avatar,
в вебе — name, posts, comments.
Сервер не меняется, меняется лишь запрос.
2. Один запрос — много данных
GraphQL позволяет собрать связанные сущности за один вызов.
В REST для этого нужно было несколько запросов, теперь достаточно одного.
3. Строгая типизация
Схема описана декларативно, и клиент может проверять запросы ещё до выполнения.
Ошибки, вроде “такого поля нет” или “тип не совпадает”, ловятся на этапе компиляции.
4. Эволюция без версий
GraphQL не требует /v1, /v2, /v3.
Добавил поле — клиенты, которые его не запрашивают, даже не заметят изменений.
Старые клиенты продолжают работать, новые используют расширенные возможности.
5. Самодокументируемость
GraphQL-сервер знает всю структуру данных.
Это позволяет автоматически генерировать документацию и визуальные IDE вроде GraphiQL или Apollo Sandbox, где можно исследовать схему и писать запросы интерактивно.
6. Почему GraphQL особенно популярен во фронтенде
Фронтенд-разработка — динамичная среда:
разные страницы требуют разные наборы данных, часто меняются требования, нужны быстрые итерации.
GraphQL идеально вписывается в этот процесс, потому что:
Разработчик фронтенда сам решает, какие поля ему нужны.
Не нужно ждать, пока backend добавит новый эндпоинт.
Данные приходят в предсказуемом виде, строго по типам.
Поддерживаются инструменты вроде Apollo Client или Relay, которые кэшируют и синхронизируют данные автоматически.
Именно поэтому GraphQL сегодня стал де-факто стандартом для фронтенд-команд крупных проектов.
REST чаще используется для внешних публичных API, gRPC — для связи микросервисов,
а GraphQL стал интерфейсом между фронтом и внутренним миром данных.
#Java #middle #GraphQL
В GraphQL всё держится на схеме (schema).
Она описывает, какие типы данных доступны, какие поля у них есть и какие операции разрешены.
Пример схемы:
type User {
id: ID!
name: String!
avatar: String
posts(limit: Int): [Post]
}
type Post {
id: ID!
title: String!
likes: Int!
}
type Query {
user(id: ID!): User
}
type — описание структуры данных, аналог класса в Java.
Query — “входная точка”, через которую клиент получает данные.
! — обязательное поле.
[Post] — список постов.GraphQL строго типизирован.
Клиент знает, какие поля доступны и какого они типа, а сервер может валидировать запрос до его выполнения.
5. Ключевые преимущества GraphQL
1. Гибкость запросов
Клиент формирует запрос под себя:
на мобильном — только name и avatar,
в вебе — name, posts, comments.
Сервер не меняется, меняется лишь запрос.
2. Один запрос — много данных
GraphQL позволяет собрать связанные сущности за один вызов.
В REST для этого нужно было несколько запросов, теперь достаточно одного.
3. Строгая типизация
Схема описана декларативно, и клиент может проверять запросы ещё до выполнения.
Ошибки, вроде “такого поля нет” или “тип не совпадает”, ловятся на этапе компиляции.
4. Эволюция без версий
GraphQL не требует /v1, /v2, /v3.
Добавил поле — клиенты, которые его не запрашивают, даже не заметят изменений.
Старые клиенты продолжают работать, новые используют расширенные возможности.
5. Самодокументируемость
GraphQL-сервер знает всю структуру данных.
Это позволяет автоматически генерировать документацию и визуальные IDE вроде GraphiQL или Apollo Sandbox, где можно исследовать схему и писать запросы интерактивно.
6. Почему GraphQL особенно популярен во фронтенде
Фронтенд-разработка — динамичная среда:
разные страницы требуют разные наборы данных, часто меняются требования, нужны быстрые итерации.
GraphQL идеально вписывается в этот процесс, потому что:
Разработчик фронтенда сам решает, какие поля ему нужны.
Не нужно ждать, пока backend добавит новый эндпоинт.
Данные приходят в предсказуемом виде, строго по типам.
Поддерживаются инструменты вроде Apollo Client или Relay, которые кэшируют и синхронизируют данные автоматически.
Именно поэтому GraphQL сегодня стал де-факто стандартом для фронтенд-команд крупных проектов.
REST чаще используется для внешних публичных API, gRPC — для связи микросервисов,
а GraphQL стал интерфейсом между фронтом и внутренним миром данных.
#Java #middle #GraphQL
👍2
Что выведет код?
#Tasks
import java.util.HashMap;
import java.util.Map;
public class Task111125 {
public static void main(String[] args) {
Map<String, Integer> map = new HashMap<>();
map.put("a", 1);
map.put("b", 2);
map.put("c", null);
map.merge("a", 10, (oldVal, newVal) -> null);
map.merge("b", 20, (oldVal, newVal) -> oldVal + newVal);
map.merge("c", 30, (oldVal, newVal) -> oldVal + newVal);
map.merge("d", 40, (oldVal, newVal) -> oldVal + newVal);
System.out.println(map.get("a"));
System.out.println(map.get("b"));
System.out.println(map.get("c"));
System.out.println(map.get("d"));
}
}
#Tasks
🔥1
Варианты ответа:
Anonymous Quiz
0%
1 22 30 40
44%
null 22 null 40
44%
null 22 30 40
11%
1 22 null 40
Вопрос с собеседований
Что такое ApplicationContext в Spring?🤓
Ответ:
ApplicationContext — это контейнер, управляющий созданием и связью бинов.
Он сканирует классы, применяет зависимости, обрабатывает аннотации и управляет жизненным циклом.
Это сердце Spring, реализующее IoC и DI.
#собеседование
Что такое ApplicationContext в Spring?
Ответ:
Он сканирует классы, применяет зависимости, обрабатывает аннотации и управляет жизненным циклом.
Это сердце Spring, реализующее IoC и DI.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1