We needed a better name that wasn't a nonsense name, that told a bit about what it is and was not already taken. So APIVIS it is! Obviously stands for API and Visual. It also starts with the first letter in the alphabet, and the .com and .io were not taken.
Then we did a long list of what needed to be done to get the rebranding done. It ended up as a long 20 points list.
We use Node.js, Google Firestore, Google ESPv2, Git, GitHub OAuth2, Node-RED, Cloudflare for DNS, Auth0 for authentication, Stripe, and Partial.ly for billing, Yandex for email, Hugo for our static website.
So there were a lot of places to fix and make sure that it doesn't break. https://www.apivis.com
I researched the best way to add users GitHub OAuth2 Apps programmatically, but you can only do that manually and each user needs their own OAuth2 App. A way to do it is to build your own OpenID Connect Provider with for example Ory's Hydra.
Another way which for me is simpler and that we need to build anyway is to build a web app (SPA) where users log in and click a button which takes them thru a workflow that saves the type of service selected (CPU, RAM, etc) and users info such as GitHub credentials in a secure way (which they enter after they created the GitHub OAuth2 App) on a managed RDB such as DynamoDB or Firestore. This way there is no need for extra servers and databases and to learn Hydra. You only have to use your tremendous ReactJS, API, and Node.js skills.
We have been working hard since October to have functional and secure SaaS https://www.rodened.com service where other makers can set up their own Node-RED server prebuilt with GitHub OAuth login and Git versioning.
I built it by wiring together Google Cloud Platform, GitHub, Partial.ly, Stripe, Netlify, StackBit, and of course Node-RED.
My brother is building all kinds of workflows in Node-RED such as chatbots with ML/AI enhanced dialogue.
The next step will be to build a React dashboard app where our users can select memory, CPU, etc. Right now we have a GCP backend that receives webhooks from Partial.ly and then run an IC pipeline to build up the server container for each subscriber.
We chose to use Partial.ly for payment processing. First, we tried to use Litch. But with Litch we were not able to transfer the user from the payment page all the way to the GCP function and the Firestore database.
Partial.ly combined with Stripe works quite well. The only problem is that they seem to have made it a bit too complicated to set up subscription offers.
Why didn't we just use Stripe for subscriptions? We wanted to get something up fast so we opted to use something that could process subscriptions without developing our own node.js server that receives webhooks from Stripe. Why reinvent the wheel? So, therefore, we selected Partial.ly for payment processing.
This is only the beginning. The next phase, marketing is also a tuff nut to crack. :-)
Wile working and building AI solutions for clients we missed a good solution for setting upp the service online.