Sono ancora un po 'confuso su quello che stai chiedendo, ma sulla base del tuo commento, penso di poterti offrire qualche consiglio. A quanto ho capito, stai principalmente chiedendo che cosa puoi essere chiamato da un "hook" e poi eseguito in background (non in tempo reale) per eseguire una sorta di aggiornamento relativo al db basato sulle chiamate fatte a un API di casa. Immagino un semplice diagramma come il seguente:
+----------------+ +------------------+
| | | |
| web app | after-signup | background |
| |+------------------>| service |
| | async-call or | |
+----------------+ "hook" +------------------+
+ ^ +
| | |
| | |
| | | update db
call API | | |
| | |
| | |
v + v
+----------+ +------------+
| | | |
| API | | Database |
+----------+ +------------+
Quindi, per quanto riguarda il modo in cui questa "chiamata asincrona" è fatta, ci sono un paio di opzioni comuni che vengono in mente.
1. Utilizzo di una coda
Forse qualcosa come Redis o RabbitMQ. In questo scenario, dopo che l'utente si è registrato, la tua applicazione web spinge alcuni valori nella coda (tutti i dati di cui il servizio in background avrebbe bisogno). Il tuo servizio in background sarebbe quindi un programma che guarda semplicemente la coda in un ciclo continuo ed elabora un oggetto quando qualcosa viene trovato in coda.
Sebbene si tratti di un approccio molto semplice, richiede l'installazione di una sorta di queue server all'interno dell'infrastruttura. In tal caso, il diagramma cambierebbe a vista:
+----------------+ +---------+ +------------------+
| | | | pop | |
| web server | push | |<-----------+| background |
| |+--------------->| queue |+----------->| service |
| | async-call | | process | |
+----------------+ | | +------------------+
+---------+ + ^ +
| | |
| | |
| | | update db
call API | | |
| | |
| | |
v + v
+---------+ +------------+
| | | |
| API | | Database |
+---------+ +------------+
Fire and Forget
L'altro approccio è configurare un semplice server Web come servizio di elaborazione. Tutta la tua applicazione web dovrà fare una richiesta HTTP fire and forget al tuo servizio. Con fire and forget intendo che non si aspetta una risposta quando si effettua la chiamata HTTP. Dovrai controllare quali librerie avrai bisogno di utilizzare per la tua lingua preferita per farlo accadere.
Quindi il tuo servizio in background, un altro servizio web in questo caso, accetterà la richiesta e inizierà l'elaborazione. Poiché il servizio di chiamata non è in attesa di una risposta, qui non c'è fretta.
Nodo
In entrambi questi scenari, puoi utilizzare NodeJS se lo desideri. Funzionerà bene per entrambi gli approcci. Tuttavia, i framework di EventMachine e Python Twisted di Ruby funzioneranno altrettanto bene se l'IO eventificato è il tuo obiettivo, nel qual caso dovrei presumere che tu stia pianificando di gestire un volume elevato di richieste / articoli in coda dalla tua applicazione we.
Fammi sapere se questo risponde alla tua domanda. Come ho detto prima, la domanda sembra abbastanza ampia, ma ho risposto a quello che potevo.