Разработване на цялостно NLP приложение за генериране на текст (част 2) — Пълен стек с FLASK, UWSGI и Nginx

Това е част 2 от поредица от истории, които показват стъпките за разработване на цялостен продукт, който да помогне при писането на новинарски статии, като предлага следващите думи от текста.

В част 1 се съсредоточихме върху генерирането на двупосочен LSTM модел, вижте тази връзка, ако още не сте я виждали:



Сега, когато имаме модел, нека започнем със създаване на приложение с пълен стек с помощта на FLASK.

FLASK е микро уеб рамка, написана на Python и добра за леки приложения като това.



Крайната структура на този проект ще бъде следната:

API

Подготвяща среда

Започваме със създаване на среда и инсталиране на библиотеките, необходими за генериране на requirement.txt в папката api.

В този случай важни библиотеки са Flask, Tensorflow (2.0.0), Pickle-mixin, numpy и python-dotenv.

Създаване на нашите Api файлове

След като създадем средата и инсталираме правилните библиотеки, започваме със създаването на файла wsgi.py.

Файлът е основният файл на нашето api приложение и основно извиква нашия клас на приложение, който се намира в нашия файл „api/application/__init__.py“.

Файлът „api/application/__init__.py“ инициира нашето приложение FLASK и извиква файла с маршрути.

Маршрутите ще кажат на Flask кой URL трябва да задейства нашите функции.

В този случай, когато се иска хостинг ip адресът на колбата, завършващ с „/read_text“, това ще задейства функцията readtext(), която впоследствие ще изпълни скрипта TextGeneratorBusiness.py, ако има повече от 5 думи във входа.

Накрая имаме файла api/app.ini.

Файлът app.ini е конфигурационният файл uwsgi.

Може би си мислите „хъм, какво е uwsgi?“ 🤔

От документацията на uWSGI:

Един уеб сървър е обърнат към външния свят. Може да обслужва файлове (HTML, изображения, CSS и т.н.) директно от файловата система. Въпреки това, той не може да говори директно с приложения на Python; има нужда от нещо, което ще изпълнява приложението, ще го захранва със заявки от уеб клиенти (като браузъри) и ще връща отговори.

Интерфейс на шлюз на уеб сървър — WSGI — върши тази работа. WSGI е стандарт на Python.

uWSGI е реализация на WSGI.

Важната част от файла е http= :8080, който ще каже на порта да комуникира с приложението api Flask.

Клиент

Сега, когато имаме Flask приложение, за да стартираме нашия бекенд, имаме нужда от Flask приложение, за да стартираме нашия фронтенд.

Подготвяща среда

Следвайки същите стъпки като за API сегмента, започваме със създаване на среда и инсталиране на библиотеките, необходими за генериране на requirement.txt в папката на клиента.

В този случай важните библиотеки за инсталиране са Flask, python-dotenv и requests.

Създаване на нашите клиентски файлове

Започваме, като структурираме нашата клиентска папка като нормално приложение за уеб страница, т.е. в нашата папка клиент/приложение създаваме следните папки: статични, шаблони.

Статичната папка ще хоства нашите css, js и изображения за уеб страницата, а папката с шаблони ще хоства нашия html файл.

Както wsgi.py, така и application/__init__.py са идентични с използваните в API сегмента.

Нашият файл routes.py вече е различен, тъй като ще хоства нашата начална страница, както и ще пренасочва html заявки за нашия бекенд.

HTML, css и JS файловете работят заедно, за да визуализират уеб страницата. Вътре в уеб страницата има текстова област, където можете да започнете да пишете статии за вашите бизнес новини, а бекендът ще ви помогне, след като въведете 5 думи.

Ядрото на предната програма се намира в JS файла, който слуша натискането на клавиш в текстовата област и изпраща XMLHttpRequest към предния край /read_text маршрут всеки път, когато се натисне интервалът.

И накрая, имаме файла client/app.ini:

които в този случай казват да комуникират с клиентското приложение Flask през порта 6060.

Nginx

Сега, след като имаме две Flask приложения, едно за фронтенда и едно за задния край, ще използваме nginx като обратен прокси, работещ като междинна проксиуслуга, която приема клиентска заявка, предава я към един или повече сървъри и впоследствие доставя отговора на сървъра на клиента.

В нашия случай Nginx ще слуша порт 80 и ще изпрати заявката до нашия клиентски сървър чрез нашия uwsgi протокол.

Заключение на част 2

Много хубаво, надявам се, че сте се насладили на нашето пътуване част 2. В част 3 ще видим как да създаваме контейнери за нашите файлове и приложения и как да ги стартираме локално с помощта на docker-compose.

Благодаря за четенето!