Skip to content
loading...
Discussion
markdown guide
 

As usual, it depends; if your environment is otherwise already complex or if you want to expose REST or GraphQL endpoints then factoring out the frontend into an independent project and deploying it separately can make a lot of sense. If you don't have a positive reason to put in the effort, don't. Laziness is a virtue; why make things more complicated than they have to be?

 

Thanks for your response! As I non-experienced developer I have a few doubts, can i ask it?

Example, the front in Netflix is React(i think so), and the back i guess is something like Java or Node, microservices, idk. How to deal with all these deploys and projects? Is like one S3 Bucket/WebApp/Heroku Project foreach one of these?

Also, expose means only for internal use of the front, or to be called from outside to be used as a integration? Because if im using the REST only for internal use of the front, idk if it makes senses to make two deploys when i could have it served all together, using something like a Proxy.

 

Complex deploys take many forms. Fundamentally code and assets have to make it from source control onto one or several servers, often with execution steps interspersed, often in a particular order (bad things happen if you apply database changes at the wrong time). You may be punching above the Elastic Beanstalk/Heroku weight class, but the rest of the scale ranges from having a multi-part continuous integration pipeline all the way to managing fleets of Kubernetes pods.

I meant "expose" as in "to users"; but that's only one possible reason to split architectures. I worked on a project back in the day where the frontend was farmed out to a Flash agency while we developed the backend, and splitting was the easiest way to ensure neither party had to wait more than necessary on the other. If whatever you're delivering is a self-contained whole and it's sufficiently simple that the need to break it up isn't obvious on its face, you probably have more important things to do than break it up!

 

What I do is install Digital Ocean servers and then deploy my apps using Ansible scripts. Over the time it has grown a bit and now each "meta project" has auto-computed values such as the URLs of all related services.

So basically it's a script that manages and applies configuration for me, all I have to do is setup the code repo URL.

 

That sounds nice! Would love to check a example, can I ?

 

Drop me a mail at r [at] delos.ltd if you want, I have some things I can show to you (privately, I still need to redact it before putting it in the wild)

 

There is NO right way!

Just read about how you should serve application in production, you simply won't use "python main.py", you might wanna use (nginx for static files serving and as a reverse proxy) and (gunicorn to serve python apps using WSGI).

Is it better to deploy separatedly using two webapps on azure(example) ?

It depends on how much you wanna scale... keep things together (monolithic) cuz you don't wanna spend too much at the beginning.

Ah, focus on the value of your app more than the infrastructure, heroku is a great example for that 😉

Classic DEV Post from Jul 30 '19

PublishTo.Dev: Scheduling article publishing on dev.to

Daniel Luna profile image