NativeScript (TS/Anlgular) z bazą MySQL

Question

Witam, jestem samoukiem z dziedziny programowania cross-platformowych aplikacji mobilnych. Korzystam z NativeScripta z językami Angular i TypeScript. Na hoście nazwa.pl mam postawioną bazę danych. Udało mi się ją podłączyć do mojego projektu za pomocą rozszerzenia. Mogę wykonać do niej zapytania i otrzymać rezultat (screen). Moje pytanie brzmi następująco: Jak wykonać to zapytanie w moim pliku wykonawczym .ts?

Answer 1

Ale skompilowny plik (ts->js) wykonuje się na serwie?

Aby połączyć się z relacyjną bazą danych z Node.js powinieneś użyć "Object Relational Mapping" w skrócie ORM np. Sequelize.

Aby połączyć się z relacyjną bazą danych z klienta musisz zrobić http request do node.js i potem jak wyżej.

Comments

powinieneś użyć "Object Relational Mapping" w skrócie ORM

a dlaczego "powinieneś"? Jeśli to nie jest jakaś duża aplikacja i struktura w bazie nie jest skomplikowana to nie widzę sensu ładowania sobie dodatkowej abstrakcji, jak masz z 2-3 strzały do bazy to można je napisać po prostu "bezpośrednio".

---

Mógłbyś przedstawić jak to wygląda "bezpośrednio'?

---

np. użyć po prostu mysql2 do połączenia z bazą lub jakiejkolwiek innej libki zależy jaką masz bazę... przy naprawdę prostych apkach wg mnie nie ma sensu usilnie pchać pierdyliona abstrakcji

---

I w czym to mysql2 jest lepsze od sequelize? Poza tym skoro używa angulara to raczej nie jest jakaś "naprawdę prosta apka"

---

Ale ja nie pisałem, że Twój sposób jest zły, tylko napisałem, że błędne jest od razu zakładanie, że "powinno" się robić tylko tak i koniec :)

A codo wielkości apki to angular tu nie ma nic do rzeczy, wiele razy robiłem już różne naprawdę mikro apki (np. proste adminki wewnętrzne itp.) gdzie było 30-50 komponentów, a nie powiesz mi chyba, że apka z 50 komponentami to jest jakiś rozbudowany twór :)?

Najlepiej niech sobie autor po prostu spróbuje zrobić coś małego np. raz przy użyciu orm, a raz bez tego i po prostu zobaczy, pozna dwie drogi. A jaką wybierze przy większej apce to zupełnie inna sprawa, ale będzie miał rozeznanie co i jak.

---

 A codo wielkości apki to angular tu nie ma nic do rzeczy, wiele razy robiłem już różne naprawdę mikro apki

przy naprawdę prostych apkach wg mnie nie ma sensu usilnie pchać pierdyliona abstrakcji

 :D

---

???

---

No te dwa cytaty sobie zaprzeczają IMO, uważasz, że nie powinno się używać Sequelize do małych apek, że "nie ma sensu usilnie pchać pierdyliona abstrakcji" ale używasz do nich Angulara?

---

nie do końca, tak na wstępie, ja wcale nie twierzę, że jakakolwiek abstrakcja jest zła, wręcz przeciwnie jest dobra, tylko warto dobierać rozwiązania sensownie i mając jakieś argumenty.

Co do API - w małych apkach często API zawiera 2-5 endointów (choć to nie jest oczywiście żadna reguła) i pytanie czy w firmie mamy ogólnie doświadczenie bardziej z libkami typu mysql czy raczej z orm'ami. Jeśli byłaby to jedyna apka w firmie z orm to pytanie, czy faktycznie chcemy iść w tą stronę, czy daje nam to jakieś realne zyski i czy inni programiści chcą w to wchodzić. Chodzi o to, aby nie zostać za chwilę z apką, którą zrobił jeden programista i tylko on chciał w tym siedzieć... ale jeśli zespół uzna, że orm jest w sumie spoko i otwiera jakieś większe perspektywy to jak najbardziej warto to rozwazyć.

Ja nie napisałem nigdzie, że Twoja propozycja jest zła, w żadnym razie. "Doczepiłem" się tylko do stwierdzenia, że Kolega "powinien" w to wchodzić w sytuacji, gdy nie znamy w zasadzie produktu, nie znamy sytuacji w firmie, nie wiemy nic o innych apkach w firmie, o zespole itp. itd.

A co do frontu - tutaj sprawa wygląda tak, że mamy w firmie parę mikroapek w vanillaJS i powiem Ci, że z perspektywy czasu widzę, że dla wielu osób wejście w taką apkę np. po kilku miesiącach i zrobienie małego ficzera zajmuje sporo czasu bo w zasadzie każda z tych apek jest mocno customowa... Do tego nie wszystkie funkcjonalności są dokładnie otestowane (a wg mnie brak testów to wielki błąd... ale niestety nie wszyscy programiści tak myślą :( )

Robiąc, nawet taką małą apkę w React czy Angular jakby z góry narzucamy pewien styl, pewne koncepcje itp. Chciażby jasny podział na komponenty, jasne mechanizmy - każdy nowy programista ma łatwy dostęp do świetnych dokumentacji obu tych narzędzi... I fakt, apka taka ma sporo nadmiarowej abstrakcji ale jej stworzenie jest szybkie, są gotowe, bardzo dobre mechanizmy testowania itp. I co bardzo ważne, kolejne osoby następne ficzery zakodują stosunkowo szybko, bo dość łatwo się w takiej apce odnaleźć.

 

O tyle :) Nie chciałem dyskutować nad tym, czy orm, angular, react, express itp. itd. są dobre czy złe - bo są bardzo dobre, tylko trzeba zawsze zrobić jakąś analizę, rozeznanie i dopiero po tym mówić, że "powinniśmy" wyrac technologię X bo... i tu seria argumentów :)

Nie jestem na tym forum jakos bardzo długo, ale dość często widzę, że sporo osób patrzy na technologie, na rózne rozwiązania itp. ze zbyt wąskiej perspektywy... Gdy my w zespole podejmujemy decyzję o zmianie jakieś technologii czy stworzeniu jakić nowych mikrousług to dyskutujemy nad zaletami i wadami różnych rozwiązań i podejmujemy świadome decyzje. Czasami np. warto zrobić jakąś apkę w React, mimo, że wolisz Angulara, bo okazuje się, że inny zespół ma gotowych 20 komponentów Reactowych które tylko wystrarczy wynieść do common repo i dość szybko zrobisz apkę bez wymyślania koła na nowo :)

Zawsze warto myśleć nie tylko o swoich upodobaniach, o tym co ja chcę tu i teraz, ale również np. o utrzymaniu aplikacji, o jej rozwoju, o tym, że za 6 miesięcy przyjdzie biznes i powie "dodajcie mi tu funkcjonalność X" i warto tworzyć aplikacje na tyle rozsądnie, aby drobne ficzery developowało się w przyszłości szybko i efektywnie.

Nie znam np. osobiście tego orm co podałeś, w back-endzie raczej siedzę w Javie/Kotlinie, ale jeśli np. jest wokół tego super społeczność, jest dobra dokumentacja, development jest przyjemniejszy, można łatwo i przyjemnie testować (to jest dla mnie jeden z głównych warunków) to jak najbardziej jestem za, ale warto podać właśnie takie konkretne argumenty :)