La locul de munca dezvolt o aplicatie ce include un API scris in Scala Play si un client in Angular 8. Trimit requesturi la secunda din client pentru a afisa cele mai recente date (un fel de real-time sa spunem).
De aici am inceput sa caut si sa ma documentez despre WebSocketuri, in incercarea de a schimba acele “requesturi la secunda” in ceva mai pro, pentru a nu mai “lovi” serverul incontinuu.
Am gasit un exemplu destul de simplu in nodejs/express si angular, utilizand socket.io (a fost prima data cand am citit o linie de node) M-am gandit ca e asemanator si in Scala, doar ca difera destul de mult. Oricum, am reusit sa gasesc o solutie (WebSockets si Actors), am creat o aplicatie de test, functioneaza, nu e implementata inca in cea principala.
In ianuarie va trebui sa incep dezvoltarea unei noi aplicatii ce are nevoie si de o parte realtime … de aici si rostul postarii. M-am gandit ca ar fi mai ok sa creez 2 api-uri, unul standard scris in Scala, iar celalalt in NodeJs strict pentru datele ce vor fi transmise in realtime. Ar duce mai mult catre microservicii ma gandeam
Credeti ca ar fi o idee buna impartirea unei noi aplicatii in felul urmator: ?
api 1 : Scala / date statice
api 2 : NodeJs / date realtime
client: Angular
db: kudu
Ca avantaj cred ca ar fi usurinta cu care as putea invata si dezvolta facilitatea asta cu nodejs (foarte asemanator cu Angular) si separarea serviciilor. Dezavantaj … cred ca o parte din date ar deveni duplicate
In orice caz, trebuie sa justific alegerea facuta
merci
Cred ca marele dezavantaj este pe partea de project management. Dezvolti mai greu in Scala, nu ai prea multi programatori, etc… Ce zici tu poate fi interesant intr-o faza de learning, altfel eu as merge pe Node cap coada.
GraphQL pe backend cu subscription e ceea ce plănuiesc eu să fac de ceva timp.
N-aș recomanda Scala fiindcă mie mi-ar lua mult să scriu un API realtime serios în el, pe când cu NodeJS/Go e trivial. (Adica ai librării rx, reactive, sunt sigur că și scala are)
Poți avea un stil funcțional și cu node cu rxJS, ramda sau lodash. Obligatoriu TypeScript.
Scuze… n-am mentionat, echipa lucreaza in Scala, toate aplicatiile sunt in Scala. Trecerea la nodejs ar fi probabil doar in cazul acestui nou proiect, strict pentru partea realtime pentru usurinta implementarii (usurinta cred eu din putinele date vazute pana acum, s-ar putea sa ma insel), este echipa de BigData si Scala a fost (inca este) singura tehnologie folosita pentru aplicatii web.
Daca rezultatul va fi unul pozitiv, probabil nodejs va fi luat in calcul pe viitor si pentru alte aplicatii.
Vad din ce in ce mai des postari despre GraphQL, cand lucram in C# foloseam OData, ma gandesc ca sunt destul de asemanatoare, are avantajele lui, dar nu pot sa spun ca l-am folosit din placere
Daca echipa nu stie deloc node, nu face greseala sa sari direct in node cu tot proiectul, e limbajul de invatat, tot api-ul de node, framework, framework de testare, trebuie sa descoperi tot ecosistemul, etc.
Nu este necesar ca tot proiectul sa fie scris intr-un singur limbaj, tu ai o problema la nivelul de transport, dar nimic nu te impiedica ca partea de business sa fie in Scala, sau orice alt limbaj, exact cum ai propus si tu. (majoritatea aplicatiilor mari sunt de fapt eterogene)
Datele duplicate sunt regula, nu exceptia in servicii, de multe ori vei tine date agregate local, de fapt dificultatea dezvoltarii sistemelor distribuite vine din managementul datelor.
Atentie! Integrarea intre microservicii/servicii se face prin API-uri, nu prin baza de date, altfel vei avea un monolit distribuit.
Nu știu ce setup ai pe acolo și ce constrângeri, dar aici chiar pot sa zic fara context că nu e o idee buna. Tine-o cu Scala all the way. Nu vrei toată complexitatea de infrastructură, tooling, deployment, maintenance, learning, etc. doar că nu e o librărie așa de simpla în Scala ptr ceva. Also, nu desconsidera polling-ul. E simplu și la volum mic (și chiar uriaș), merge bine.
Otoh, ce pare într-adevăr ciudat din design e Kudu. Care pare o bază de date columnara / de analytics. Pe care nu as vedeao in serving path-ul vreunui sistem public. Aici chiar as fi curios de detalii.
Ieri am testat un mic serviciu in nodejs, nu e atat de simplu precum pare, apar tot felul de cazuri ce necesita documentare in plus. Pe langa asta, mi-am dat seama ca daca voi avea doua api-uri (scala & nodejs) va trebui sa am si un sistem de autentificare central, baza de date pentru fiecare (ceea ce nu cred ca o sa se intample). S-ar putea sa ma complic mai mult decat este necesar cu divizarea asta si mai bine o las deoparte. Multumesc pentru explicatii
Nu lucrez de prea mult timp cu actualele tehnologii, din ce inteleg eu, kudu suporta mai bine decat mysql bulkinserturi de sute de mii de linii si un numar mai mare de requesturi (analiza realtime).
Daca exista infrastructură la tine la companie pentru chestiile astea și sunt deja alese de către “arhitecți” (într-o accepțiune largă a termenului), și tu doar construiești pe baza stabilită, atunci presupun că e OK. Daca nu … Run like hell spre regular DBs. Non-standard stuff devine nevesar la o scară foarte mare și crescândă an de an. Iar pe partea operațională o să te mănânce cu fulgi cu tot. Stick with MySql/Postgres/MSSQL/etc pana nu se mai poate mai degrabă
M-am gandit ca e asemanator si in Scala, doar ca difera destul de mult. Oricum, am reusit sa gasesc o solutie (WebSockets si Actors), am creat o aplicatie de test, functioneaza, nu e implementata inca in cea principala.
