Що таке проміжне програмне забезпечення? Визначення та приклади використання

Проміжне програмне забезпечення - це загальновживаний термін у веб-розробці. Це може означати багато речей залежно від контексту, що робить цей термін дещо заплутаним.

У цій статті ми почнемо з визначення терміна, а потім продовжимо обговорення деяких різних випадків використання.

Прочитавши цю статтю, ви зможете більше брати участь у технічних та архітектурних бесідах зі своїми однолітками. Ви також зможете спроможніше розробляти безпечні та надійні API та потоки даних.

Визначення проміжного програмного забезпечення

Проміжне програмне забезпечення - це програмне забезпечення, яке виступає посередником між двома програмами чи послугами для полегшення їх спілкування.

Ви можете сприймати це як проксі-сервер, який може діяти як накопичувач даних, перекладач або просто проксі-сервер, який пересилає запити.

Поширені випадки використання проміжного програмного забезпечення

1) Перекладач

Існує багато форматів обміну даними, таких як JSON, XML та Protobuf. Незважаючи на те, що сьогодні ми в основному використовуємо JSON, кожен із них має власні випадки використання.

Наприклад, протобуфери, як відомо, ефективніші за JSON, але вони не читаються людиною. Отже, ви можете використовувати протобуфери для внутрішніх служб, і ви можете використовувати JSON, коли споживач API є браузером.

Ви також можете переглянути мою статтю про протобуфери, якщо вам цікаво дізнатись більше про них.

Тепер, скажімо, нам потрібні ці дві служби, які говорять за різними протоколами, для спілкування між собою.

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

2) Накопичувальні та дублюючі дані

Архітектура мікросервісу - це популярний архітектурний шаблон, який зазвичай застосовується в сучасних додатках.

Якщо ви не знайомі з архітектурою мікросервісів, це в основному означає, що ваш додаток складається з безлічі невеликих додатків або служб, які не залежать одна від одної та працюють разом, спілкуючись через Інтернет.

Наприклад, у проекті електронної комерції у вас може бути мікросервіс для зберігання та отримання продуктів, інший мікросервіс для пошуку та ще один для автентифікації та зберігання користувачів. І у кожного своя база даних.

Тепер скажімо, що ми хочемо реалізувати свій пошук таким чином, щоб він шукав як користувачів, так і продукти.

Якби це була монолітна програма, ми могли б просто написати запит на пошук у кожній таблиці та об’єднання результатів. Але зараз наші бази даних працюють на різних серверах.

Ця проблема має кілька рішень, і ми розглянемо два з них.

Накопичувальні дані

Ми можемо використовувати проміжне програмне забезпечення для надсилання запитів на обидва сервери та просити їх шукати у своїх базах даних імена користувачів та продукти, які відповідають пошуковому слову.

Тоді ми можемо накопичувати результати з обох серверів і повертати їх клієнту. Зверніть увагу, що кількість запитів збільшується лінійно, коли ми збільшуємо кількість серверів (і нам також потрібно об’єднати ці дані).

Дублювання даних

Ми можемо зберігати дублікати даних на нашому пошуковому сервері, щоб він міг безпосередньо шукати їх, а не запитувати з серверів продуктів та користувачів. Це менш ефективно з точки зору пам'яті, але набагато швидше - і швидкість є критичною для пошукових служб.

Якщо нам потрібні таблиці Product і User, ми можемо створити ці таблиці і на нашому пошуковому сервері. Потім кожного разу, коли ми зберігаємо нового користувача в нашій базі даних, ми також зберігаємо одну копію на пошуковому сервері.

У нас є кілька варіантів: по-перше, ми можемо викликати методи збереження сервера пошуку з методів збереження серверів користувачів та продуктів, щоб дублювати дані. Або ми можемо створити проміжне програмне забезпечення для збереження, яке буде робити наступне:

  • Щоразу, коли надходить запит на збереження, телефонуйте на збереження продукту / сервера користувача та на збереження сервера пошуку.
  • Якщо перше збереження не вдається, не викликайте збереження на іншому (це підтримує узгодженість баз даних).

Давайте розглянемо схеми проектування без проміжного програмного забезпечення та з ним. По-перше, ось як це виглядає без:

Виглядає потворно, правда? Дійсно, це негарно, і це зробить ваш код більш складним і тісно пов’язаним.

Ось таке саме рішення з проміжним програмним забезпеченням:

У цьому випадку клієнтська сторона просто викликає проміжне програмне забезпечення, щоб зберегти продукт чи користувача, а решта обробляє.

Немає коду, пов'язаного з дублюванням даних, ні на Продукті, ні на Серверах користувачів, ні на стороні клієнта. Проміжне забезпечення дбає про ці речі.

3) Безпека API

Для будь-якого зовнішнього коду на стороні клієнта ми можемо переглядати вихідні запити на консолі браузера або через проксі-сервер.

Ми говорили про сервер користувача, який дбає про вхід та реєстрацію. Якщо наш інтерфейсний код безпосередньо надсилає запити на цей сервер, відкривається адреса нашого сервера автентифікації. Дізнавшись IP-адресу нашого серверного сервера, зловмисники можуть використовувати інструменти для пошуку наших кінцевих точок та сканування нашого сервера на наявність уразливостей.

Ми можемо використовувати проміжне програмне забезпечення як проксі, щоб приховати URL-адресу нашого сервера автентифікації. Наш інтерфейс взаємодіє із проміжним програмним забезпеченням, і він перенаправить запит на сервер автентифікації та поверне відповідь назад.

Цей підхід також дозволяє нам блокувати всі запити до нашого сервера автентифікації, крім запитів із URL-адреси нашого проміжного програмного забезпечення. Це робить наш сервер автентифікації набагато безпечнішим.

Раніше це було неможливо, оскільки наш інтерфейс спілкувався із сервером автентифікації. Оскільки інтерфейс означає комп'ютер клієнта, ми не змогли застосувати фільтр IP.

4) Розкриття загальнодоступних API

У попередній частині ми дізналися, що проміжні програми можна використовувати для обмеження доступу до нашого API.

А тепер давайте розглянемо іншу сторону рівняння: що, якщо ми хочемо надати обмежений доступ до нашого API? Можливо, ми інженер-програміст у банку, і банк планує хакатон. Нам потрібно було б надати доступ до нашого API, правда?

Але оскільки ми є банком, звичайно, ми не можемо надати доступ до всього API і дозволити кожну операцію. Це означає, що нам потрібно знайти спосіб забезпечити обмежений доступ.

Для цього ми можемо реалізувати проміжне програмне забезпечення, яке виставляє лише деякі кінцеві точки і перенаправляє запити на наш фактичний API. Потім ми надаємо цей API розробникам на хакатоні.

Висновок

У цій публікації ми розпочали з визначення того, що таке проміжне програмне забезпечення, і спробували класифікувати випадки використання проміжних програм у веб-розробці.

Майте на увазі, що це далеко не повний перелік варіантів використання, але все-таки я сподіваюся, що це було корисно для вас.

Дякую за читання. Якщо вам сподобалась стаття, я запрошую вас переглянути мій блог. Ви також можете підписатися на мій список розсилки, щоб отримувати сповіщення, коли я публікую нове повідомлення :)