Closed theawesomew closed 1 year ago
ONG prolly not - it'll come up in networking tab lmao
https://vercel.com/guides/getting-started-with-nextjs-typescript-stripe This looks useful, and obviously we can ignore the final step for deploying on Vercel.
I suppose we could create an API route on coopsoc's website itself. The vulnerability will be there but, it would require some substantial effort to retrieve the API key on the user's part and I can't see that being done by anyone. I'm happy to greenlight this if everyone else is.
Need to read into it more but creating our own API looks better than using google sheets’ API
I wouldn't mind using Google Sheets anyway - purely because using something like SQL Server or MongoDB would require that we create a presentable front-end which like... effort. But, we'll use the API in the backend.
And I'm no longer much of a fan of using the front-end to make API requests purely because it creates the risk of exposing the API key and that creates a serious security risk - even if we can mitigate by making multiple redirects; we still run a considerable risk.
I'm going to make the call that we host the backend on the web server in my home or we utilize Heroku - either one suffices.
Wait so to clarify - the frontend will make API requests to our custom Go backend, running on your web server. The Go server will then make API requests to stripe, mail receipts, and generate invoices. That way, we don't risk making the Stripe API keys public, right?
That is absolutely correct on all fronts. That will likely mean I should secure my home webserver more than I presently have to ensure maximum security but, you're absolutely right.
We'd prefer to avoid having to create and deploy a payment microservice to enable customers to purchase Co-op Society merchandise - primarily because we'd need to pay for the hosting of such a microservice and we'd like to avoid incurring costs wherever possible.
My proposal is we use
This is NOT recommended in serious production systems as storing API keys in .env is a bad idea. If someone ever gets access to our environment variables and has malicious intentions, they can easily make a series of API calls to 'refund' transactions that never occurred; but, we're unlikely to be a target of that kind of attack.
If we don't want to go down that avenue, we'll develop a backend in whatever language you'd like and deploy it here or wherever else y'all think is a good hosting service (maybe AWS)