Planowanie architektury aplikacji webowej z użyciem Express.js i React (REST API)

Poziom studencko-juniorski.
Do tej pory pracowałem w połączeniu: Spring (back) i Angular (front), gdzie nie korzystałem z obcych API (serwisy informacyjne, portale społecznościowe, pogoda, itp), chyba że były to wewnętrzne mikroserwisy w pracy.
W celu poprawy znajomości JavaScript, TypeScript oraz nauki React postanowiłem napisać aplikację webową, dla której stworzyłem dwa repozytoria: Express.js (back) i React (front). Aplikacja musi zawierać logowanie i rejestrację.

System ma za zadanie pobierać, a następnie obrabiać dane giełdowe(dokonywać obliczeń) przykładowo takiego JSONa:
https://www.quandl.com/api/v3/datasets/WSE/CDPROJEKT.json?api_key=MqbK19YZ9jDT8asyvzN-
Następnie wizualizować dane w zależności od wybranego okresu np. 1 dzień, 1 miesiąc, 1 rok i inne takie....

Planuję zatem mechanikę powyższego procesu:
I. W części backendowej pobierz JSONa z Quandl (GET od obcego API).
II. Obrób te dane tzn. oblicz wskaźniki giełdowe, oscylatory, itp. w części backendowej.
III. Stwórz własne endpointy w backendowym repozytorium, w których będziesz wysyłał obrobione dane (POST od własnego API).
IV. Odbierz te dane w części frontendowej (GET od własnego API), doczytując m.in. o axiosach w React.

Wobec tego, chciałbym Wam zadać pytania:

1. Czy dobór Express.js dla planowego backendu nie wydaje się dziwny - może lepiej wykorzystać np. Nest.js?
2. Czy szkic tego rozwiązania z takim obcym i własnym API jest w porządku?
3. Czy warto rozważyć biblioteki typu math.js lub Immutable.js do implementacji wskaźników giełdowych, oscylatorów, itp?
4. Czy należy unikać wspomnianych obliczeń w części frontendowej, nawet gdy wynikają bezpośrednio z JSONa, np. sum, średnich?
5. Jak wizualizować te dane w React nie zaśmiecając kodu i aplikacji (aby nie było zbyt dużego korzystania z REST API, bo danych matematycznych będzie dużo jak na apkę pisaną popołudniami). Nie oczekuję na to pytanie odpowiedzi, bardziej czy możecie doradzić na jakie technologie / słowa klucze w React powinienem zwrócić uwagę?

Ad.1 Nie ma nic dziwnego w używaniu Ekxprssa - masz jakieś konkretne wątpliwości związane z Twoją apką?

Ad.2&4 Przepuszczanie obcego API przez własny backend jest ok - możesz wyfiltrować niepotrzebne dane, zarządzać dostępem do danych itp. Co do obliczeń - jak zwykle, to zależy:

• nie ma sensu robić na backendzie obliczeń czysto prezentacyjnych jeśli i tak wysyłasz bazowe dane do tego samego widoku (np do narysowania wykresu),
• nie ma sensu wysyłać bazowych danych gdy pokazujesz tylko współczynniki, wtedy lepiej obliczyć to na backendzie,
• jeśli korzystasz zarówno z bazowych danych jak i wyliczeń na ich podstawie, ale na innych widokach wtedy wchodzą w grę detale by zdecydować co jest bardziej ekonomiczne / szybsze / wygodniejsze / łatwiejsze w rozwoju / lepsze dla docelowego użytkownika.

Ad.3 To zależy, pamiętaj, że każda dodatkowa zależność ma swój koszt. Jeśli obliczenia są na tyle zaawansowane by uzasadnić Math.js to bierz, ale nie na zasadzie - nie chce mi się pisać funkcji na trzy linie to użyję gotowca. Co do Immutable.js - lubię koncept, jakby coś takiego było wbudowane w JS to bym był przeszczęśliwy, jednak jako osobna biblioteka, dla większości aplikacji uważam to za overkill, zwykle natywne typy + trochę dyscypliny wystarczy.

Ad.5 Jeśli zdecydujesz, że obliczenia będą na serwerze to po prostu nie rozdrabniaj niepotrzbnie API, nie rób endpointów dla pojedynczych wskaźników, tylko coś w stylu /companies/:id/indicators lub /indicators/:id (kompletnie się nie znam na giełdzie, wiec traktuj to tylko jako pokazanie konceptu). Jeśli wskażników będzie dużo a nie wszystki będą potrzebne jednocześnie to możesz je podzielić na grupy, lub sparametryzować zapytania by uniknąć nadmiernego overfetchingu. Innym popularnym w światku Reacta rozwiązaniem na overfetching jest GraphQL, ale on ma własne bolączki (było o tym na mikroblogu ostatnio -> GraphQL - krytyka Ileż to za... ), jednak polecam najpierw popróbować z RESTem.
Co do samego Reacta - pamiętaj o podziale komponentów - container components vs presentational components (możesz też popróbować z Reduksem).