Best practices for storing ID tokens and sending w

I'm very new to this overwhelming world of WEBSITE push notifications. I would appreciate it if someone could show me the right path with the best practices. Again, it's about WEBSITE push notifications using Firebase.

My testing website is hosted on Azure and I use .Net plattform in c# environment with SQL server.

I've already red and "memorised" the Firebase google documentation. I also tested how to retrieve a token, refresh it... and send a notification to a specific device using postman.

However I still have many question marks.

My first question: What is the best practice for saving the tokens once received on the server? In an SQL database?

function sendTokenToServer(currentToken) { 
if (!isTokenSentToServer()) { 
console.log('Sending token to server...'); 
setTokenSentToServer(true); 
} else {
console.log('Token already sent to server so won\'t send it again ' + 
'unless it changes');
}

Second question: Now let's say I have 50.000 subscribers in the database, what is the best practice to send dynamically ONE push notifications to all of them, WITHOUT GROUPING OR TOPICS? And which is the most secure delivery method POST, CURL, FETCH... Let's assume I'm using FETCH, how can I send the same notification to those 50.000 subscribers. Through a database loop? Or?

var key = 'YOUR-SERVER-KEY';
var to = 'YOUR-IID-TOKEN';
var notification = {
'title': 'Portugal vs. Denmark',
'body': '5 to 1',
'icon': 'firebase-logo.png',
'click_action': 'http://localhost:8081'
};

fetch('https://fcm.googleapis.com/fcm/send', {
'method': 'POST',
'headers': {
'Authorization': 'key=' + key,
'Content-Type': 'application/json'
 },
'body': JSON.stringify({
'notification': notification,
'to': to
})
})

.then(function(response) {
console.log(response);
}).catch(function(error) {
console.error(error);
})

My third question: Can I use instead .Net and C# to accomplish the above method of sending one single notifications to my 50.000 subscribers? Any hints about a sample code?

"The one who asks a stupid question might sound stupid for a short time, however the one who doesn't dare to ask a stupid question will remain stupid for the rest of his/her life"

Thank you!

Not sure what best practices are you looking for, but so long as you're abel to store the token and identify which user it is for, then that's about it.
If it's a different message per token, you have no other choice but to loop each one. If it's the same message, use registration_ids and send to 1000 tokens per request -- still using a loop. The request type needed for using the API is POST.
Haven't tried it on either one, sorry. But so long as you could send an HTTP POST Request, then that's it.