За пунктами: що треба знати про бекенд новачкові у веб-розробці


Дізнайтесь більше про нові кар'єрні можливості в EchoUA. Цікаві проекти, ринкова оплата, гарний колектив. Надсилайте резюме та приєднуйтеся до нас.

У цій статті перераховані ключові аспекти, які треба враховувати при створенні бекенду в контексті full – stack веб-розробки. Новачків вона познайомить з основами, а більш досвідченим  програмістам може бути корисна в якості чек-листа.

1. Аутентифікація

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

Можна виділити два основні типи аутентифікації:

  1. Що запам’ятовує попередній стан – реалізується за допомогою сесій. Користувач авторизується один раз, а потім дістає можливість вільно пересуватися по додатку і отримує доступ до захищених ресурсів (таким, як банківські транзакції або селфі в Snapchat), не відправляючи дані, які підтверджують його вхід повторно.
  2. Що не запам’ятовує попередній стан – реалізується за допомогою токенів. Користувачі роблять все те ж саме, але при виконанні кожного HTTP-запиту користувачеві треба відправляти ідентифікаційні дані. Так зазвичай поступають з REST API. Зараз золотий стандарт, аутентифікації, що не запам’ятовує стан, з токенами – JWT.

Є і кращий сценарій – багатофакторна аутентифікація. Вона підвищує безпеку додатка, додаючи додаткові рівні захисту до логіна і пароля. Хороші приклади реалізації є у Google і Amazon.

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

2. Ролі, дозволи і контроль доступу

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

Заплуталися? Поясню детальніше. Сенс авторизації – це видача дозволів, підтримка безпеки особистої інформації, відмова в доступі до конкретних дій і, де вимагається, анулювання привілеїв, щоб одні користувачі не пробиралися в акаунти інших і не дивилися їх особисті фотографії. Логіка дозволів проста:

Користувач x може зробити дію y з об’єктом z.

Застосуємо це в конкретній ситуації: Шерон – редактор і може редагувати пости. Тоді потрібно визначити:

  • роль Шерон – редактор;
  • її дія – редагування;
  • об’єкти, з якими вона може це робити, – пости.

Як це працює? Просто: булеві змінні. Ви повертаєте True/False залежно від того, що і кому дозволено робити з конкретним об’єктом. Отже, чи може Шерон редагувати якийсь конкретний пост? Повернути True, якщо вона редактор, повернути False і закрити доступ до поста, якщо ні.

3. CRUD – Create, Read, Update, Delete

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

Але що таке ресурс? Якщо ви створюєте книжковий магазин, то книги – це ресурси. Якщо ви створюєте групу, вона сама і є ресурс і її учасники теж ресурси. А також кожен запис або аккаунт, який вони використовують. Наприклад, це може бути офіційний лист до уряду, листівка або фільм, який вони намагаються купити.

Тут і з’являється модель структури ваших даних. Вам треба буде розуміти, як вирішити наступні завдання:

  • як створювати нові дані;
  • як їх редагувати;
  • як я їх оновлювати і видаляти.

Так виглядає CRUD при роботі з фреймворком Ruby on Rail, який надає шар об’єктно-реляційного зіставлення (Object Relational Mapping – ORM):

# створюємо новий запис про студентеstudent = Student.new (:first_name => 'Ann', :last_name => 'Smith', :birthday => '1986-08-11') # зберігаємо створений вище записstudent.save

Також ваші ресурси рідко існують в ізоляції. Найчастіше вони пов’язані якимись стосунками або асоціаціями з іншими ресурсами. Давайте поглянемо на сценарій, де ви хочете зберегти інформацію про пари, які є у студента. Ви можете створити дочірній ресурс student і зберегти його:

student.classes.new (:name => 'Geometry').save

Чи не так, це виглядає і читається, як звичайна англійська? Але вчитися все одно доведеться, адже в реальності завдання дуже швидко обростають труднощами! Тому вам треба навчитися працювати з базами даних, вибравши для себе відповідну модель: реляційну чи NoSQL.

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

4. REST

Щоб забезпечити управління ресурсами у вашому застосуванні (такими, як книги або аккаунти), треба реалізувати програмний шар, що приймає запити і формує відповіді. Тут вам доведеться попрацювати з маршрутами (routes) і контроллерами (controllers). Вони забезпечують дотримання обмежень, що накладаються REST – стилем архітектури програмного забезпечення для розподілених систем.

У типовому застосуванні на Ruby маршрут виглядає так:

get '/photos/:id', to: 'photos#show'

Що в цей час відбувається в системі:

  1. Приходить запит на фото з цим маршрутом і передається контроллеру за допомогою методу show.
  2. Цей метод, звертаючись до ресурсу з бази даних або до іншого API, формує і передає відповідь у форматі HTML або JSON.
  3. Клієнт (в даному випадку браузер комп’ютера) отримує відповідь і виводить фото на екран.

Запити можуть приходити з багатьох джерел (їх називають клієнтами). Найчастіше запити для веб-застосування формуються у формі введення браузеру. Але, якщо ви пишете бекенд для мобільного застосування, то клієнт – це API додатка, і він посилає запити GET, POST, PUT, DELETE з додатка.

Ви можете розробити систему, що відповідає на запити, створивши API з урахуванням REST. Такий API називається RESTful.

5. Форми і стани

Форми – це найпоширеніший спосіб спілкування користувачів з додатком. В основному через них користувачі і вводять усі дані.

Вам потрібно створити форми для взаємодії з бекендом: якщо користувач замовляє квиток на концерт, то форма повинна виглядати, як сітка місць:

Коли користувач починає взаємодіяти з формою, вам потрібно зробити наступне:

  1. Грунтуючись на правилах додатка, перевірити введену користувачем інформацію і показати помилки або повідомлення про успішну перевірку.
  2. Змінити назву стану або форми залежно від того, хто і що намагається зробити.
  3. Дозволити передачу даних, введених перевіреним користувачем з достатніми правами, у бекенд для обробки.

6. API

Щоб ваше застосування стало по-справжньому популярним, вам потрібно почати ділитися даними з іншими застосуваннями. Наприклад, ви – музична компанія, і ви хочете, щоб стримінгові сервіси типу SoundCloud постачали ваш контент, а користувачі могли купувати вашу музику безпосередньо з їх застосування. Тут і потрібний API.

Термін API – абревіатура від Application Programming Interface (інтерфейс програмування додатків) – застосовується до інфраструктури, яка дозволяє іншим застосуванням взаємодіяти з вашим.

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

Основні етапи написання API:

  1. Створити API-сервер. Етап має на увазі забезпечення захищеного доступу до ресурсів, які ви хочете передавати клієнтам. Якщо у вас книжковий магазин, то ваш API надаватиме назви книг, ціни і інформацію про видавця іншим сайтам і перекупникам.
  2. Захистити сервер, використовуючи ідентифікатори додатків і секретні ключі.
  3. Зробити зрозумілу інтерактивну документацію, яка дозволить іншим розробникам переглядати її і взаємодіяти між собою і з вами.

7. Повідомлення по Email, SMS і Webhooks

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

Повідомлення – це спосіб повідомити вашого користувача про статус виконання дії і допомогти йому організувати робочий процес у вашому застосуванні.

Для різних випадків ви можете використати різні повідомлення:

  • сповіщення на екрані додатка;
  • електронні листи (верифікація пошти або підтвердження купівлі);
  • SMS (авторизація або завершення транзакції);
  • webhook-повідомлення в реальному часі для тих, що звернулися до вашого додатка чат-ботів на різних платформах, наприклад, Facebook, Telegram або Slack;
  • регулярні листи з рахунками за покупки і інформацією про оплату підписки.

8. Підписка і тарифні плани

Продумування тарифів тільки здається не дуже важливим, але насправді часто є необхідним. Вам доведеться навчитися створювати багаторівневі тарифні плани і привласнювати певні ролі, дозволи і привілеї користувачам, що підписалися на конкретний план. Також хороша ідея навчитися надавати динамічне ціноутворення, грунтоване на властивостях, що формують кожен тарифний план. Наприклад, купівля нового сервера на AWS або DigitalOcean надає користувачам право вибирати пам’ять, процесор і так далі

Корисні поради по проектуванню тарифних планів:

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

9. Взаємодія з платіжним шлюзом

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

Під час транзакції треба:

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

Ви також можете використати сторонні сервіси, такі, як Paypal, які дозволяють інтегрувати їх інтерфейс у вигляді форми (чи кнопки) у ваше застосування, і тоді транзакції частково управлятимуться цим сервісом.

Не забувайте про рахунки – людям потрібні документи про транзакції для сплати податків і т. д.:

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

Як працює платіжний шлюз:

  1. Ваші касові форми відправляють деталі купівлі на платіжний шлюз для обробки.
  2. Платіжний шлюз передає ці транзакції банку продавця.
  3. Банк продавця передає цю інформацію про транзакцію банку, який випустив карту покупця, для авторизації транзакції.
  4. Банк, який випустив карту покупця, або схвалює, або відхиляє транзакцію і відправляє інформацію банку продавця.
  5. Якщо транзакція схвалена, то банк переказує кошти на ваш рахунок.
  6. Після схвалення сторонній платіжний шлюз відправляє деталі транзакції і відповідь вашому застосуванню.
  7. І, нарешті, ви відправляєте повідомлення покупцеві, повідомляючи, чи схвалена транзакція.

Якщо залишилися питання, подивіться це відео:

10. Завантаження файлів

Дуже ймовірно, що коли користувачі почнуть працювати у вашому застосуванні, вони зберігатимуть у ньому свої дані, які представляють з себе не лише інформацію у вашій базі, але і картинки, відео і PDF. Так що вам буде потрібно:

  1. Дозволити завантажувати тільки файли певних форматів.
  2. Перевіряти файли на перевищення дозволеного розміру і відхиляти завантаження занадто великих.
  3. Показувати користувачеві процес завантаження.
  4. Переконатися, що завантаження відбувається асихронно і не порушує роботу фронтенда.
  5. Дозволити користувачеві позначати файли як особисті/загальнодоступні.
  6. Дозволити користувачеві експортувати завантажені дані.
  7. Створити медіа-бібліотеку, щоб фільтрувати файли і управляти ними (опціонально).

11. Сторонні API, фреймворки і пакети

Ruby, Elixir, PHP і JavaScript вже мають тисячі пакетів, які можуть бути налагоджені і застосовані до вашого застосування. Їх легко вбудувати за допомогою команди в один рядок в терміналі:

# аутентифікація в Rails:gem install devise # відладка і профілізація в Laravel:composer install clockwork # аутентифікація в Express:npm install passport

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

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

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

12. Робота з Open Source

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

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

13. Інтерфейс для управління

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

Хороша панель управління повинна мати наступні властивості:

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

14. Кешування

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

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

Як працює кешування у веб-застосуваннях? Можна виділити наступні типи механізмів:

  • кешування контенту. Якщо контент веб-сторінки не змінюється постійно, то немає нужди кожного разу наново його генерувати. Ціла HTML-сторінка може бути збережена в кеші;
  • кешування фрагментів. Іноді ціла сторінка не може бути закешована, тому що на ній є контент, який постійно змінюється, але є і частини, які змінюються повільно. HTML для цих статичних частин генерується тільки при першому запиті, а при повторних витягається з кеша;
  • кешування даних. Часто в основі веб-застосування лежить база даних, але кожного разу витягати з неї інформацію досить невигідно, тому часто використовувані дані кешуються в пам’яті додатка або в інших сховищах, наприклад, Redis, Varnish і Memcached.

15. Компоненти

Це більше відноситься до фронтенду, але оскільки ви full – stack розробник, вам треба розділити ваш код – і шаблони сторінок, і служби бекенду – на модульні компоненти, якщо ви не хочете заплутатися. У моєму улюбленому проекті фронтенд організований таким чином:

{% include ' components/global/ header' %}{% include ' components/services/ masthead' %}{% include ' components/services/ svc-stats blok' %}{% include ' components/services/ client-list' %}{% include ' components/services/ sol-portfolio' with { 'brandColor': BrCore } %}{% include ' components/services/ customers-blok' with { 'brandColor': BrCore, 'topConnector': true } %}{% include ' components/services/ why-aranca-c' %}{% include ' components/services/ svc box grid' with {'data': entry.experienceRichtext, 'brandColor': BrCore } %}
{% include ' components/services/ featured-case-study' %}{% if entry.tfilterRichtext|length %} {% include ' components/services/ table-filter' %}{% endif %}{% include ' components/services/ full-cta-a' %}{% include ' components/services/ kc-content' %}{% include ' components/global/ footer' %}

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

16. Системи управління версіями

Звичайно, йдеться про використання Git і GitHub. Новачкам використання Git здається зайвим, а його переваги – неочевидними, тому пропоную подумати про ситуації, з якими ви можете зіткнутися в процесі написання коду:

  1. Якщо ви збираєтеся працювати з іншими розробниками над одним і тим же проектом, то ви користуватиметеся загальним набором файлів. Як саме ви плануєте уникнути протиріч при змінах в коді?
  2. Що, якщо ви захочете повернути стару версію і подивитися, як ви реалізували те або інше завдання перед тим, як продовжите розробку?
  3. Що, якщо ви захочете відкотити проект до останньої версії, в якій ще не було збою?
  4. Що, якщо ви захочете поділитися своїм початковим кодом? Ви його архівуватимете і розсилатимете по e-mail при додаванні кожної нової фічі?
  5. Як ви стежитимете за тим, які файли були змінені, а які – ні?

Навчитися користуватися GitHub допоможе ця стаття.

17. Командний рядок

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

Для освоєння командного рядка раджу цю книгу.

18. Питання на Stack Overflow

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

Переклад статті “Part uh: what does it take to be a full stack developer”?

Київ, Харків, Одеса, Дніпро, Запоріжжя, Кривий Ріг, Вінниця, Херсон, Черкаси, Житомир, Хмельницький, Чернівці, Рівне, Івано-Франківськ, Кременчук, Тернопіль, Луцьк, Ужгород, Кам'янець-Подільський, Стрий - за статистикою саме з цих міст програмісти найбільше переїжджають працювати до Львова. А Ви розглядаєте relocate?


Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *