4 messaggi dal 22 luglio 2019
Salve.
Ho bisogno di realizzare un server rest che implementi una serie di webhook. Ho ancora poca esperienza in c# e specialmente in .net core, ma credo che il progetto sia parecchio lineare e tradizionale.

Contemporaneamente devo implementare gli stessi webhook all'interno di un programma desktop, magari tramite endpoint socket, in modo che i client che vi si collegano possano funzionare indifferentemente sia online in presenza di connessione, che in rete locale in sua assenza.
Considerando che sul desktop non è possibile (o comunque non è garantito che lo sia) installare IIS.

Al momento sono in una fase di studio/esplorazione, quel che vi chiedo è se sia possibile minimizzare il lavoro e gli errori, riutilizzando tutta la logica.
Ammetto di avere le idee abbastanza confuse. :P
11.868 messaggi dal 09 febbraio 2002
Contributi
Ciao e benvenuto nel forum!


Ho bisogno di realizzare un server rest che implementi una serie di webhook.
...
gli stessi webhook all'interno di un programma desktop

Penso che i webhook non siano una buona soluzione in questo caso. Infatti, è improbabile che tu riesca a raggiungere i clienti desktop a causa di firewall, nat et similia.

Forse è meglio fare in modo che siano i client a collegarsi al server in maniera persistente grazie a websockets, così che il server possa sfruttare la connessione esistente per inviare messaggi quando lo reputa opportuno. Dunque dovresti guardare come funziona ASP.NET Core SignalR, che ti permette di inviare messaggi in maniera bidirezionale, sia in formato testuale che binario.

Spiega bene cosa devi realizzare così potrò darti una risposta più precisa.

ciao,
Moreno
Modificato da BrightSoul il 22 luglio 2019 21:56 -

Enjoy learning and just keep making
4 messaggi dal 22 luglio 2019
Spiegherò meglio il progetto.
Lo scopo principale è quello di realizzare un progetto che funzioni in rete locale su normali computer e smartphone, e che appena possibile sincronizzi tutto su un server web.
Doppio salto mortale: all'occorrenza i client devono poter saltare il server della rete locale, e collegarsi a quello remoto.

Ci sarà un server remoto tradizionale (SR), a cui tutti i client (C) possono collegarsi, che contiene un database, e tutti i metodi previsti (es.: crud utenti).

Poi ci sarà anche un server locale (SL), che contiene una copia del database, le cui righe man mano vengono sincronizzate su SR. SL può essere un qualsiasi computer presente nella rete locale.

I client sono per lo più smartphone collegati nella stessa rete wifi di SL, e che vi si collegano tramite browser. Le app per i client saranno realizzate in Angular.

Per le autorizzazioni di rete per SL ho già del codice testato per verificare la presenza di autorizzazioni sul firewall, ed eventualmente richiedere all'utente di concederle.

Mi rendo conto che sia tutto molto macchinoso.
Il mio obiettivo in questo momento è di semplificare il più possibile, ed aumentare la ridondanza del codice tra SR ed SL per evitare errori dovuti alla differente implementazione dei metodi.

I socket in questo caso possono essere più vantaggiosi dei webhook? E aggiungono livelli di complessità?
Suggerimenti vari?
11.868 messaggi dal 09 febbraio 2002
Contributi
Ciao,
credo che in questo caso non si debbano usare né socket né webhook. Chi ti ha parlato di queste soluzioni e perché?

Penso che il client Angular debba semplicemente collegarsi a una API Rest che puoi realizzare con ASP.NET Core Web API. Il problema, quindi, non è tanto come far comunicare client e server ma capire qual è il ruolo di SL e SR.

Domande:
  • SL è un fallback di SR? Cioè i client devono sempre e comunque provare a connettersi a SR e usare SL solo se non c'è connettività? Oppure sono i client a scegliere l'uno o l'altro?
  • Ci sono client che hanno accesso solo a SR e non a SL (se ad esempio si collegano al di fuori della rete locale)?;
  • E la domanda più importante di tutte: hai pensato a come far riconciliare i dati? Cioè, se utente A modifica il cliente Mario Rossi su SR e utente B lo modifica su SL, quale modifica vince? Dipende dalla data/ora? Dipende dall'utente? Dipende dai campi modificati?


ciao,
Moreno
Modificato da BrightSoul il 29 luglio 2019 13:28 -

Enjoy learning and just keep making
4 messaggi dal 22 luglio 2019
Grazie sempre per le risposte!

- SR funge backup, e da origine centralizzata dei dati, per una questione di velocità e suddivisione del carico i client accedono ad SL, che se possibile e quando necessario farà da proxy verso SR per accedere ad alcuni dati.
- I client sono di due tipologie, suddivise per scopo. Una accede solo ad SL, un'altra accede solo ad SR per avere dati aggregati anche se a discapito della completezza. Salvo casi eccezionali comunque si prevede che siano quasi sempre allineati. All'occorrenza
- Ehhhhhh... Ottima domanda... Intanto per la sincronizzazione pensavo di utilizzare su ogni database un campo contenente l'id della PK sull'altro database. Come risolvere i conflitti è un bel problema, penso che alla fine andrà valutato differentemente a seconda della tipologia di dato, ma ancora non esiste una politica in proposito.
11.868 messaggi dal 09 febbraio 2002
Contributi
Ciao, credo che questo progetto diventerà molto complesso molto velocemente. Affidatevi a un consulente il prima possibile, in modo che vi aiuti a distillare dei requisiti e che vi affianchi nella progettazione dell'architettura.


Come risolvere i conflitti è un bel problema ma ancora non esiste una politica in proposito.

Se la specifica non è chiara, è probabile che il progetto fallisca con dispendio di tempo e denaro. Ripeto: serve un consulente.

Io ti do il mio punto di vista che *potrebbe* semplificare un po' il progetto. Ma è un'opinione così, senza averci ragionato su e senza conoscere approfonditamente lo scenario:
  • SR è l'unica fonte di verità ed è l'unico che può essere usato sia per leggere che per scrivere. Si trova su Azure, in modo che sia sempre altamente disponibile. Ovviamente, se i client locali non hanno connessione ad internet, i dati non si potranno salvare perché il database sarà irraggiungibile;
  • Usi SQL Data Sync per creare SL, che sarà una replica in sola lettura di SR;
  • I client che si trovano in locale potranno accedere ad SL come "copia cache" di SR, in modo da ridurre un po' le latenze e i costi di Azure. Se internet non è disponibile, i client potranno quantomeno leggere ma non potranno scrivere dato che SR sarà irraggiungibile.


In questo modo eviteresti di dover riconciliare i dati a livello applicativo, che non è banale da fare.

ciao,
Moreno

Enjoy learning and just keep making
4 messaggi dal 22 luglio 2019
Purtoppo (per me) non è possibile: SR deve rimanere opzionale.
Data Sync però è una cosa interessante che non conoscevo.

Intanto credo di aver risolto la condivisione del codice tra API su SR, e servizio su SL. Anche se per adesso più che altro è solo la finestrella di una console lanciata in debug sul mio computer.

Per adesso mi sto concentrando su quale DB adottare nel server locale, che potrebbe essere qualunque cosa da un box con atom ad un portatile scassato.
I requisiti principali sono: affidabilità, sicurezza dei dati, supporto a query avanzate, semplicità di gestione, leggerezza.
Affidabilità nel senso che l'ideale sarebbe qualcosa di basico come un file access, nel senso di qualcosa che si copia sul pc che funge da SL, e funziona. Ovviamente access non rispetta gli altri requisiti, verrebbe spontaneo affidarsi quindi ad SQL Server, ma per esperienza con altri software i tempi di installazione sono estremamente lunghi, ed a volte capita che il servizio non parta in automatico all'avvio.
La sicurezza dei dati è altrettanto importante perchè verranno conservati dati sensibili. L'ideale sarebbe che oltre a criptare i dati all'interno dei campi, riuscisse a nascondere anche la struttura delle tabelle.

Ho ristretto le possibilità alle seguenti soluzioni.
- SQL Server Express: permetterebbe di semplificare la sincronizzazione con il server remoto, ma non ho ancora capito se sia possibile utilizzarlo senza lunghe installazioni sul computer del cliente, e se le soluzioni di sicurezza che adotta siano adeguate.
- SQLite: immenso boh su tanti fronti, ma dato che il software vi si collega come se fosse un mdb, dovrebbe garantire un buon livello di affidabilità, semplicità di gestione, e leggerezza su macchine datate.

Cosa mi consiglieresti? E cosa sto dimenticando?
11.868 messaggi dal 09 febbraio 2002
Contributi
Ciao,

affidabilità, sicurezza dei dati, supporto a query avanzate, semplicità di gestione, leggerezza.

Dovresti mettere queste cose in ordine di priorità perché è difficile trovarle tutte in un unico prodotto.
Per esempio, se la tua priorità è garantire la sicurezza dei dati, non puoi usare Access su un portatile. Ricorda che la normativa del GDPR ti richiede anche di non perderli, i dati e di mettere in piedi un'infrastruttura che ti consenta di rilevare eventuali accessi non autorizzati.
https://www.ilcorrieredellasicurezza.it/data-loss-prevention-in-ottica-gdpr-limportanza-di-proteggere-i-dati-da-furti-esterni-e-interni-al-perimetro-aziendale/

un box con atom ad un portatile scassato

Temo che tu stia ampiamente sottovalutando il problema, per questo ribadisco che dovresti affidarti a un consulente.
Un cliente che voglia mettersi in casa un server, oggi non può prescindere dal compiere un certo investimento sia per quanto riguarda l'hardware che nella rivisitazione delle pratiche di accesso ai dati. Serve almeno un server con hardware ridondato.
Sta a te e ai tuoi colleghi educare i vostri clienti sulla necessità di affrontare una certa spesa (per il loro benessere) e un'osservazione attenta delle buone pratiche di sicurezza.
Probabilmente, scegliendo di ospitare il server on-premise, finiranno per spendere di più di un servizio cloud che già impiega diverse accortezze a livello di sicurezza.

A proposito del database, io sceglierei SQL Server 2017 o Sql Azure. Ecco le funzionalità che offrono in merito di protezione dei dati.

Una presentazione:
https://www.slideshare.net/gax700/la-gestione-dei-database-secondo-il-gdpr-sql-server

Una brochure PDF:
http://download.microsoft.com/documents/en-gb/microsoft-sql-and-the-gdpr.pdf

ciao,
Moreno
Modificato da BrightSoul il 07 agosto 2019 21:53 -

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.