Tail Call Optimization (TCO) — это оптимизация, которая позволяет не создавать новый стековый кадр (stack frame) для вызова функции, если вызывающая функция просто возвращает результат этой функции.
Чаще всего это встречается при хвостовой рекурсии (tail recursion).
Допустим, у вас есть рекурсивная функция:

const recur = (args) => {
    doSomething(args);
    return recur();
}

Представим, что программа начинает работу с первого вызова recur(). Назовём его Call 1.
Внутри Call 1 происходит ещё один вызов recur(). Назовём его Call 2.
При любом вызове функции компилятор или интерпретатор создаёт стековый кадр для хранения данных текущего вызова.

Стековый кадр нужен для того, чтобы сохранить состояние Call 1 на случай, если после возврата из Call 2 ему ещё понадобится выполнить какую-то работу.
Но каждый новый стековый кадр занимает память и увеличивает размер стека.

Если все рекурсивные вызовы имеют вид:

return recur();

то после завершения Call 2 у Call 1 больше нет никакой работы. Он просто сразу возвращает полученный результат.

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

В результате новые кадры стека не создаются, а потребление памяти остаётся постоянным:

O(1)

вместо обычного:

O(n)

для рекурсии.

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

👉 @BackendPortal

Open NotebookLM — бесплатная open-source альтернатива NotebookLM.
Генерирует подкасты и позволяет общаться со своими документами через чат.

https://github.com/lfnovo/open-notebook

👉 @BackendPortal

API Design Complete Roadmap
|
| | |-- Fundamentals
| |-- Introduction to APIs
| | |-- What is an API
| | |-- API architecture basics
| | |-- Client-server communication
| |-- Types of APIs
| | |-- REST APIs
| | |-- GraphQL APIs
| | |-- SOAP APIs
| | |-- gRPC APIs
| |-- HTTP Fundamentals
| | |-- Requests and responses
| | |-- HTTP methods
| | |-- Status codes

| | |-- REST API Design
| |-- Resource-Based Design
| | |-- Nouns over verbs
| | |-- Resource naming conventions
| |-- CRUD Operations
| | |-- GET
| | |-- POST
| | |-- PUT/PATCH
| | |-- DELETE
| |-- URI Design
| | |-- Clean URLs
| | |-- Nested resources

| | |-- Request & Response Design
| |-- JSON Best Practices
| | |-- Consistent structures
| | |-- Error responses
| |-- Data Validation
| | |-- Input validation
| | |-- Output formatting
| |-- Pagination
| | |-- Offset pagination
| | |-- Cursor pagination

| | |-- Authentication & Authorization
| |-- API Keys
| |-- JWT Authentication
| |-- OAuth 2.0
| |-- Role-Based Access Control (RBAC)
| |-- Permission Management

| | |-- API Security
| |-- HTTPS
| |-- Rate Limiting
| |-- CORS
| |-- Input Sanitization
| |-- Preventing API Abuse
| |-- Secure Secret Management

| | |-- API Documentation
| |-- OpenAPI Specification
| |-- Swagger UI
| |-- API Reference Docs
| |-- Request Examples
| |-- SDK Documentation

| | |-- API Versioning
| |-- URL Versioning
| |-- Header Versioning
| |-- Semantic Versioning
| |-- Backward Compatibility

| | |-- Performance Optimization
| |-- Caching Strategies
| | |-- Browser caching
| | |-- Server-side caching
| |-- Compression
| |-- Query Optimization
| |-- Response Time Monitoring

| | |-- Advanced API Patterns
| |-- GraphQL Fundamentals
| |-- gRPC Services
| |-- WebSockets
| |-- Event-Driven APIs
| |-- API Gateway Pattern
| |-- Microservices Communication

| | |-- Testing APIs
| |-- Unit Testing
| |-- Integration Testing
| |-- End-to-End Testing
| |-- Postman Testing
| |-- Automated API Testing

| | |-- Monitoring & Observability
| |-- Logging
| |-- Metrics Collection
| |-- Distributed Tracing
| |-- Error Tracking
| |-- API Analytics

| | |-- Deployment & Scalability
| |-- Docker for APIs
| |-- Kubernetes Basics
| |-- Load Balancing
| |-- Horizontal Scaling
| |-- CI/CD for APIs

| | |-- Real World Projects
| |-- Design a RESTful Blog API
| |-- Build an E-commerce API
| |-- Create a Chat Application API
| |-- Develop a Payment Gateway API
| |-- Build a URL Shortener API
| |-- Design a Social Media API

| | |-- Interview Preparation
| |-- REST API Interview Questions
| |-- Authentication Scenarios
| |-- API Security Challenges
| |-- System Design for APIs
| |-- Performance Optimization Questions

| | |-- Community and Growth
| |-- Build Public API Projects
| |-- Publish APIs on GitHub
| |-- Write API Design Articles
| |-- Contribute to Open Source
| |-- Stay Updated with API Standards

👉 @BackendPortal

В 2006 году один разработчик из Мумбаи начал писать менеджер электронных книг для себя.

Спустя почти 20 лет его проектом пользуются около 3 миллионов человек из 236 стран каждые два месяца.

Его зовут Ковид Гоял. Проект называется Calibre. И да, он до сих пор остаётся главным разработчиком. Последний релиз вышел всего неделю назад.

Calibre бесплатный, open-source и распространяется под GPL-3.0. Работает на Windows, macOS и Linux.

Что умеет:

• читает почти любой формат электронных книг: EPUB, MOBI, AZW, AZW3, KFX, PDF, CBR, CBZ, DOCX, TXT и другие;
• конвертирует книги между форматами в пару кликов;
• редактирует метаданные, обложки и теги;
• управляет библиотеками на тысячи книг;
• отправляет книги напрямую на Kindle, Kobo, Tolino, телефон или планшет;
• умеет поднимать локальный сервер, чтобы читать свою библиотеку через браузер.

Сейчас у проекта почти 25 тысяч звёзд на GitHub и около 2.9 миллиона активных установок за последние 60 дней.

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

Настоящая цифровая библиотека выглядит именно так: книги принадлежат тебе, а не экосистеме устройства.

https://github.com/janeczku/calibre-web

👉 @BackendPortal

Это тот самый гайд, который мне хотелось бы получить в первый день изучения Computer Science.
В нём шаг за шагом объясняется, начиная с одного транзистора, почему компьютер большую часть времени не занимается вычислениями, а просто ждёт данные из памяти. По сути, он гораздо меньше похож на калькулятор, чем кажется.

Понимание этой идеи полностью изменило то, как я читаю и пишу код, и автор постарался объяснить её так, чтобы это стало понятно и вам.

Если вы до сих пор не разобрались, что такое memory wall, то упускаете один из самых сильных моментов «озарения» во всей компьютерной науке.

Автору потребовалось больше 20 дней глубокого ресёрча и много работы, чтобы изложить это максимально просто.
Вот статья: https://abhisheklearn12.github.io/blogs/memory.html

👉 @BackendPortal

Хотите понять, как подключить LLM к реальным рабочим процессам, а не просто гонять промпты в чате?
В этом курсе Ania Kubów показывает, как собрать и задеплоить AI-агента для Slack с нуля.

По ходу курса вы:
• Поднимете Slack-бота на базе GPT-4.
• Настроите Node.js, Express и Slack Bolt.
• Подключите PostgreSQL для хранения данных.
• Развернёте проект через Render.
• Научите агента искать и привлекать новых участников сообщества.
Получается не очередной демо-чатбот, а полноценный агент, встроенный в рабочий процесс команды.

Курс: Build Your Own AI Agent with Node.js and Slack

👉 @BackendPortal

Если делаешь приложение или API, где важна скорость ответа, Redis может сильно разгрузить бэкенд.

Вместо того чтобы каждый запрос снова лез в базу данных, часто запрашиваемые данные кладутся в память. Следующие запросы получают их сразу из кэша, без лишних обращений к БД.
Маниш разобрал, как работает in-memory кэширование в Redis, как его настроить и как внедрить на реальном примере.

Полезный материал для тех, кто хочет уменьшить задержки, снизить нагрузку на базу и ускорить API.
https://freecodecamp.org/news/how-in-memory-caching-works-in-redis/

👉 @BackendPortal

Один вопрос по Kubernetes, который мне попадается снова и снова на собеседованиях:

Что происходит с запросом на пути от интернета до Pod'а?

Обычно ответ выглядит так:
User → ALB → Ingress → Service → Pod
И вроде всё правильно.

Но самое интересное начинается после этого.
Следом обычно спрашивают:
• Кто выбирает Pod, который получит запрос?
• Чем на самом деле занимается kube-proxy?
• Как работают iptables и IPVS?
• Зачем нужен CNI-плагин?
• Что будет с трафиком, если kube-proxy упадёт?

Для меня одним из самых полезных инсайтов было вот что:
Service в Kubernetes сам по себе не балансирует трафик.
kube-proxy создаёт правила iptables/IPVS на нодах, и именно они направляют запросы в живые Pod'ы.

Ещё интереснее становится, когда речь заходит об отказах.
Если kube-proxy упадёт, трафик обычно не перестаёт ходить мгновенно. Существующие правила уже находятся в ядре Linux и продолжают работать.

Ломается другое: Kubernetes больше не может обновлять эти правила, когда появляются новые Pod'ы, удаляются старые или меняются Service.

Смешно, но именно такие базовые вопросы чаще всего вскрывают самые глубокие пробелы в понимании Кюбернетеса.

👉 @BackendPortal