Вибираємо правильний стек для розробки ПЗ під POS

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Взагалі все, що пов’язане з грошима для нас, людей, досить чутливе. Не дай Бог кудись не туди одна чи дві копійки піде і це буде справжній кошмар. І добре, коли сума невелика, сумно звичайно, але не смертельно. Але якщо суми сягають захмарних чисел? Ось тут вже треба бути дуже уважним.

Для розробки таких застосунків часто використовують старі, добрі та всім відомі React або Angular, завдяки яким можна розробити досить простий та зрозумілий інтерфейс додатку. В той час, як для бекенду часто використовують Node.js або Python, рідше можна побачити варіант з PHP, але я не фанат збочень (РНР — мейнери, пробачте, будь ласка). Ну а як СУБД можна використати стандартні MySQL або MongoDB.

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

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
рідше можна побачити варіант з PHP,

Навпаки, частий вибір в Україні.

Poster
Ядро системы работает на JS + PHP.
dou.ua/...​ticles/optimizing-deploy

Поділіться своїм досвідом в коментарях, цікаво буде почитати.

Приймав участь.
Бекенд на Node.js
Фронтенд React+Next, ReactNative для Android
База Postgre

Звичайна розробка.
Нюанси тільки в роботі з залізом, еквайрінг пристрої та принтери, та з сервером податкової.

Стейкхолдер хтів своє рішення мати, а так можна взагалі уникати цих подробиць
Є checkbox.ua і подібні

Можете трохи розказати про ці нюанси? Що взагалі було найскладніше при розробці продукту такого роду?

Можете трохи розказати про ці нюанси?

Не бодався з ними. Боротьба з принтерами та екварійнг приблудами — то окрема тема, і зазвичай не впливає на розробку. В нас займалась спочатку одна людина, а потім взагалі віддали на «аутсорс», і склали список «сумісного обладнання».

«Підключенная касових апаратів» у любому проєкті зараз зазвичай робить представник продавця цих апаратів, який співпрацює з програмістами.

Так давно — наприклад і в світі 1С — є драйвер? підлючаєм.
Немає? ну то купіть касовий апарат у якого він є.
Або найміть з політеху якогось, хто напише.

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

Що взагалі було найскладніше при розробці продукту такого роду?

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

Хоча, особливим можна назвати тільки роботу з сервером податкової.
Там вимоги суворі, а опис не прозорий, тому є даже форум, де колективно пишеться документація, і навіть програмісти з податкової там більше пояснюють, аніж в офіційній документації :)
гуглити «Касова зміна на ПРРО»

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

Підписатись на коментарі