Struktura Projektu - Rest API, SSR

Question

Wymyśliłem sobie projekt - sklep internetowy, ale dosyć nietypowy także wszelkie gotowce typu Presta etc. odpadają, poza tym takie rozwiązania mnie nie motywują.

Z racji tego że pracuje jako front(JS,Vue,SSR), ale też zdarzyło mi się coś napisać w node czy react, do projektu użyję:

- VueSSR (front sklepu, panel klienta dla kupującego)

- ReactJS (panel sprzedającego + panel admina)

- Express (rest api, mail, optymalizacja zdjęć, jwt)

- MongoDB

Dlaczego taka kombinacja?

VueSSR - najdłużej w tym piszę - szybko zakoduje front

ReactJS - można pomyśleć dlaczego też nie Vue, odpowiedź jest taka że nigdy nic większego w React nie napisałem + większy rynek pracy, projekt w react widoczny tylko dla poszczególnych osób także mogę sobie pozwolić na jakiś błąd

Node/Express - ze względu na JS i czas

MongoDB - tutaj się zastanawiam czy mongo czy mysql lub inna relacyjna. Póki co wybrałem mongodb ze względu na to że jest łatwiejszy(chyba?) a co za tym idzie szybiej napisze, nigdy nie pracowałem z mysql.

Pytania:

1. MongoDB vs MySQL dla "sklepu", jak bardzo może to być zły wybór jeśli zdecyduje się na NoSQL?

2. Chce aby rest api i sklep stały na osobnych VPS'ach. Czy zazwyczaj się tak robi?

Jakieś inne sugestie?

Stan projektu: skonfigurowany VPS, pisanie rest api + security, także z tą bazą mogę jeszcze zmienić i się douczyć:D

Answer 1

1. Nie widzę powodu aby używać bazy nierelacyjnej w projekcie, w którym spójność i relacje danych mają duże znaczenie.
2. To zależy od obciążenia ale w SPA request po aplikację jest jeden na długi czas. Także nie bawiłbym się w takie podziały. Na tym etapie projektu jest to przedwczesna optymalizacja.

Comments

Ad 1. Nie zgodzę się, pracuję w projekcie gdzie relacje są istotne ale jest wiele baz mongo, cassandra itp. Relacje to tylko jeden z elementow przy wyborze bazy, np. Takie mongo z mojego doswiadczenia wynika, ze lepiej sie skaluje j zarzadza, szczególnie pod wiekszym ruchem gdzie bazy mysql, oracle itp. częściej wyglądają. A relacje można zapewnić w API. Kolejna rzecz, dokumenty nosql latwiej i szybciej zmigrowac niz bazę z wieloma relacjami itp. Dwa, rozhudowa np. Kolekcji mongo o nowe pole nie wymaga od razu przemodelowania pelnej bazy.

---

lepiej sie skaluje j zarzadza

Myślę, że przy prywatnych projektach akurat aspekt skali jest najmniejszym problemem.

---

Przy małych proj owszem, ale wydaje mi się że czesto ludzie na siłę biorą np. MySQL gdzie mongo znacznie ulatwiloby im prace... panuje tu na forum jakiś kult mysql jakby to była jedyna słuszna baza. A jesli chodzi np. o poziom trudnosci to szczerze nie widzę zadnej różnicy, obie bazy maja bardzo dobrą dokumentacje.

Ja komercyjnie ponad 80 procent proj mam na nierelacyjnych i wg mnie ma to naprawdę sporo zalet i przyjemniej się z tym pracuje.

---

Ja kiedyś się bawiłem z Mongo, ale akurat dobrałem go do takiego projektu, że tam de facto 95% zabawy z danymi to były relacje. No i myślałem, że mnie wywiozą w kaftanie ;)

Kult SQL bierze się stąd, że spora część projektów webowych używa sporej liczby relacji. A tego typu aplikacje o wiele łatwiej modelować na SQL niż NOSQL. Zwłaszcza, że w MongoDB o strukturę danych trzeba dbać na poziomie API, bo baza pozwala na sporą dowolność. To sprawdza się dobrze w projektach, gdzie relacje nie są takie istotne, a same dane można łatwo przedstawić jako JSON/YAML, względnie XML. Tutaj dobrym przykładem byłby blog, gdzie każdy post może mieć dodatkowe metadane, niedostępne w innych postach. Ale już np. dziennik elektroniczny dla szkół łatwiej IMO zrobić na SQL, gdzie baza ma wszelkie potrzebne mechanizmy do egzekwowania spójności danych i relacji między nimi.

Pomijam przy tym fak, że od jakiegoś czasu PostgreSQL można wykorzystywać podobnie do baz opartych na kolekcjach w JSON/BSON, dzięki nowemu typowi pól przechowujących właśnie JSON ;)

---

Zresztą w idealnym świecie problem by nie istniał, bo cała interakcja z bazą danych byłaby przykryta warstwą tłumaczącą dane z bazy na format strawny dla aplikacji. Jeśli aplikacja wiedziałaby tylko o tej warstwie, to pod spodem można by było dowolnie podmieniać SQL na NOSQL, bez żadnego wpływu na samą aplikację.

No ale nie żyjemy w takim świecie ;)

---

o to już zupełnie inny temat, w 100% się z Tobą zgadzam, ale niestety nie zawsze jest to takie proste do wykonania... Oczywiście jakiś poziom abstrakcji należy zachować, chociażby dla ułatwienia sobie rozwoju aplikacji itp. Ale stworzenie tak zupełnie niezależnem abstrakcji jest ciężkim tematem...

Co innego gdy tworzymy jakąś apkę zupełnie od podstaw, ale przy już istniejących bytach jakoś tego nie widzę... Pracuję obecnie w projekcie, gdzie mamy ponad 700 mikrousług back-endowych plus masę mikrofrontendów i jak to w życiu bywa, każdy robi troszkę po swojemu... :)

Aczkolwiek w jakiś małych projektach, gdzie jest max kilkanaście mikrousług czy w ogóle jeden back-end to można faktycznie pomyśleć nad takimi bardziej uniwersalnymi rozwiązaniami. Tylko znowu pytanie, jakie jest ryzyko w takich małych projektach, że będziesz musiał zmieniać bazę i czy warto iść w taką abstrakcję :)

Oczywiście nie jestem jakimś mega przeciwnikiem baz relacyjnych, sam z nich korzystam w niektórych sytuacjach ale bardziej jednak skłaniam się ku tzw. nosql (choć nie lubię tej nazwy...) Narzędzia do pracy z np. mongo też są bardzo spoko, ja korzystam ze Studio 3T i jestem bardzo zadowolony.

---

Dziękuje wszystkim za odpowiedzi.
Dla wyjaśnienia dodam jeszcze że projekt ten nie zamierzam schować do szuflady a pokazać "światu". Mam lekko ponad 2 lata doświadczania i od początku we froncie, a że wymyśliłem projekt na którym nikt nie może nic stracić(nawet mimo wtopy) a ja mogę zyskać sporo wiedzy w kierunku node'a i react'a + może jakies $, to mnie bardziej motywuje. 

Co do bazy danych, ja głównie się kierowałem tym że lepiej mi się zarządza mongo oraz tym że jak relacyjną źle zaprojektuje(a tak pewnie by było przez częste zmiany) to będzie gorzej to naprostować niż mongo. Studio 3T jeszcze nie sprawdzałem, z GUI póki co poznałem tylko compass'a. Oczywiście baza będzie zarządzana z poziomu api. Kolejny powód że mam i tak dużo tutoriali do przerobienia + testów i praktyki z samego node'a i projektowania rest api. Dołożenie do tego nauki projektowania baz relacyjnych to dla mnie zapewne kilka dodatkowych miesięcy, jak nie więcej. A nie chciałbym robić tego projektu w nie skończoność.

 

To zależy od obciążenia ale w SPA request po aplikację jest jeden na długi czas. Także nie bawiłbym się w takie podziały. Na tym etapie projektu jest to przedwczesna optymalizacja.

W tym przypadku bardziej myślałem o SSR, z każdym przeładowaniem strony serwer będzie pytał o nowe dane, zakładam że będzie ich sporo i niezbędna będzie również paginacja.