Frontend / Backend separate deployment
valentierra opened this issue · 4 comments
Hi Tiangolo
Hope everything is going great from your side!
Just a "tactical" question about how would be the best approach to accommodate this full-stack to be deployed separately:
Frontend
Netlify recently incorporated Vue to the frameworks available for deployments. To take advantage of this new feature, once you built full-stack-fastapi-couchbase's frontend, what would have to take into account to allow the exchange of information with the backend?
Backend
AWS/GCP/Heroku support the containerisation of several services. I read the dockerswarm.rocks info but when you don't have root access and not explicit IPs, how could I securely expose each service/container of the swarm to be connected by the frontend running on Netlify?
Cheers and thanks in advance for your attention!
Recently I came across Zeit and was impressed by its integration of services towards the serverless. I am trying to develop the Zeit builders for this full-stack. I think this is the best approach for those who just want to devote themselves to developing their own application.
Hi @valentierra ! Sorry for the delay.
I guess that using those tools/services you probably wouldn't use/need containers. The drawback might be the vendor locking I guess.
Frontend on Netlify
You can have your frontend built on Netlify building servers directly. Or if you want to do it in Docker, you can push the built code as part of the build process.
In Netlify you would get a somecustomdomain.netlify.com. You can set a DNS record (a CNAME) to point somecustomdomain.com to somecustomdomain.netlify.com. That way, whenever someone goes to somecustomdomain.com, they will see your content served from Netlify.
Frontend CORS
Then you just have to add that domain to your CORS in your backend (in the backend.env file if you use a recent version of this stack).
And that's it, it doesn't matter that your frontend is actually served by Netlify, as long as your backend has the host (https://somecustomdomain.com) in its configuration of CORS.
Backend in AWS/GCP
AWS and GCP can provide you virtual machine instances. Those are just standard Linux instances. You normally have sudo in those machines. And normally, each instance gets a fixed public IP for as long as it exists.
If you plan on removing them and changing them and you want to keep a fixed IP, you can add "floating IPs" (each one has its name for them) and then redirect them to your VM.
Backend in PaaS, Heroku, Google App Engine, etc
If you use one of the "platform as a service" systems, where you don't have control of an actual Linux instance behind, but you just provide your code to some system and it runs it, you are, more or less, in their hands. Some people like it some don't. Setting up IPs, ports, domains, HTTPS, all that is done through their custom private systems.
In that case, you would probably also use one of their "database as a service", like Heroku's Postgres, AWS and Google Cloud have their own versions and also several custom "NoSQL" versions. You would probably not use Couchbase in that scenario. But you would have to adapt your code to use those databases.
Less things to worry yourself (they handle the DB) in exchange of more vendor locking and price fee.
Backend in Function as a service
If you want to use one of the Function as a service (also called "serverless") systems, you might want to try https://github.com/erm/mangum, with it, you can put FastAPI in one of these services.
This gives even more responsibility to the service provider.
Thank you @tiangolo!
Impeccable answer! Your feedback is much appreciated!
I am closing the issue but keep posting if I find something with the merit to add/comment.
Cheers!
Awesome, thanks!