Comment on page
Технически изисквания
Изисквания към техническата разработка на проекта с отворен код Подкрепи.бг.
Да се създаде безплатна и напълно прозрачна онлайн платформа за дарения, която да може да се използва свободно от граждани и организации.
- Кодът на Проекта трябва да е публичен и това да не компрометира сигурността;
- Да има публична и лична част на платформата;
- Всеки да може да се регистрира с популярни социални платформи (Google, Facebook);
- Дарителите да имат възможност да останат анонимни, ако желаят;
- Всички работни пароли трябва да се намират извън кода на Проекта.
- Да има добра документация:
- на архитектурата;
- на връзките между компонентите;
- на API ниво чрез swagger или подобни инструменти.
- Да се използват разпространени технологии и работни рамки (frameworks);
- Да се използва език със стриктно типизиране;
- Да поддържа бърза разработка на стандартни функционалности;
- Да може да се стартира целият Проект локално, без голямо натоварване и сложност;
- Да има безопасни за разработка среди (dev, staging);
- Да има автоматично:
- проверка на стила на кода;
- тестване при създаване на pull request;
- създаване на контейнери;
- качване на кода към различните среди.
- По възможност, да се преизползват общи:
- правила за валидация на frontend и backend;
- типове на данните;
- константни стойности;
- преводи;
- функционалности.
- По възможност, да се използва един и същи език за програмиране.
- Да се избягват директни външни промени по базата данни;
- Всеки потребител да има достъп само до своите данни;
- Да има автоматични тестове, които потвърждават липсата на изтичане на данни;
- Всички заявки за включване на код да минават през код ревю процес, включващ повече от един технически координатор.
- Всяка промяна на базата данни да се записва;
- Всяко качване или изтриване на файл да се записва;
- Да има вътрешни статистики за употребата на платформата;
- Да се пазят статистиките за определено време;
- Да има скалиране на системата за одит при повишаване на трафика.
- Потребителите да имат достъп само до своите и споделените им файлове;
- Потребителите да могат да свалят всичките си файлове при желание (GDPR);
- Да има автоматично резервно копие на файловете във външна за платформата среда.
- Да се използва установена и стабилна база данни;
- Д а се използват миграции на базата данни;
- Да се използват отделни потребители с ограничени права за различни нужди;
- Да се използват общи типове на данните за тип на колоните (домейн, тип);
- Да се използва row level security (RLS), при възможност.
- Да бъде подходящо оразмерена спрямо нуждите на платформата;
- Да поддържа платформата в добро общо състояние;
- Да има добра видимост над натоварването на платформата;
- Да разпределя трафика към различните модули;
- Да бъде осигурена с контрол на достъпа;
- При възможност, да поддържа автоматично скалиране, при повече трафик.
- Да се съхранява кодът за възстановяване на системата (manifests);
- Да се извършват автоматични резервни копия на базата данни;
- Да се извършват автоматични резервни копия на хранилището за файлове;
- Да има ясна процедура по възстановяване на резервни копия.
- Да се въведат рейт лимити на входящите заявки;
- Да се използват системи за превенция на DDoS атаки;
- Да има мрежови ограничения за намаляване рисковете от злоупотреби;
- Базите данни да не са достъпни извън Системата;
- Да има валидация на входящите данни на всеки слой.
- Графична библиотека:
- Основен транспорт на данни:
- REST:
- Работна рамка:
- TypeScript:
- DB driven:
- База данни:
- Postgres
- ORM:
- Миграции:
- Kubernetes:
- Управляван от доставчика на облачни услуги
- On premise
- Docker-compose (локално):
- On premise
Бяха взети предвид следните съображения:
- документация;
- примерни проекти;
- включени стандартни компоненти:
- сигурност:
- oбработка на грешки
Използвайки една база и една схема, вместо отделни, ние даваме възможност да се изгради начална работеща версия на приложението, без излишни технически препятствия. Когато се намери подходящ сценарий, който изисква отделни схеми и бази, той ще бъде имплементиран.
Подходящо решение, което да ни позволи бързо действие и еднотипни промени по базата, е Prisma, свързана с PostgreSQL.
Чрез това решение ние:
- ще намалим времето за разписване на схемата на базата;
- ще се подсигурим, че връзките между обектите са в синхрон;
- ще генерираме типове за обектите в базата автоматично;
- ще генерираме миграционни скриптове автоматично.
Разбира се, това решение, както и всички останали, би имало недостатъци:
Last modified 1yr ago