File structure on my server
I've ubuntu running on a digital ocean droplet that I was planning on using to clone a github repo of mine that I use locally.
In that repo I have my usual
dev/build folder structure, so I can build locally, but that'll mean when I pull the repo from my server it'll have all the dev files. Just wondering if this matters, or if there's a better way to do it?
Sorry if this seems simple, but this is my first time sorting my own server 🙂
Thanks16 Replies
Ideally, you want to have only the strictly necessary files/packages in your server. You mentioned that you have a build folder, I assume is this because of React or something else (TypeScript) that requires compilation? Those things will drain more resources needlessly, it's best to have it done on the development machine or a dedicated build server.
You might want to look into CI/CD with GitLab or GitHub Actions. This can compile your code so that all you have to do is push your code to these platforms
ah, no so I develop on my local machine, and that machine has access to a remote git repo. The server also has ssh access to that repo. So I git push from my local machine, and then git pull from my server.
That pull includes both my build folder and my dev folder 🙂
So I'm still building on my local machine (I think!)
Are you running any intermediate steps between development and deployment? Like compiling TypeScript down to JavaScript or building a React application, etc.?
I'm running webpack, but it's vanilla js for the moment
but yeah, the contents of dev and build are different if that's what you're asking?
So, you are committing the build folder to the git repository as well?
yes, both dev and build. Not sure I'd know how to commit the build folder to a separate repo, but I guess that would do it?
Although I'm not entirely sure what problem I'm even trying to sidestep here XD
I see, well, the problem I see is that you don't normally commit the build folder to your repo
Similar to how you never commit the node_modules folder, since you can always re-download it from the "source code" (in this case the package.json). You should re-build the code on your development machine and upload it directly to the server.
It's best to get things to work first which you've already done. Now you want to improve on that.
So if I'm building locally, but not committing the build, doesn't that in effect mean I shouldn't be using git as a way to upload files to the server?
That's right, git shouldn't be used to send files except those of the source code.
What things like GitHub Actions do is detect changes on the git repository and run a series of build steps, then upload the code the server. That way the developer doesn't even have to run the build locally, and the server gets only what it needs to run and nothing more, all automated.
You could also run the build on your server when you pull the source code from the repo, and I would argue that's a better setup. However this still requires the server to have development files installed, even if you can delete them later, and run the build process which will consume resources that other apps could use. For smaller setups this is fine and it's a good way of incrementally improve the deployment process
ok cool, will definitely try github actions - found a good digitalocean guide on implementing it.
Unfortunately I've got like 2 days to do a crap-ton of work, so if the other alternative to github actions is building on the server (and having the related dev files regardless) I might stick with the process I've got, committing both, and change it next week when I've more time. Unless there's any particular issue with build files in github?
I'm surprised though, because this git set up was taught by Jem Young on Frontend Masters. I'll have to have a word XD
thanks for your help though, much appreciated
Sure
Like everything in programming there's tons of solutions to the same problem, all with their own pros and cons
I'm sure they found that commiting everything to git was very easy for most people to follow along. This setup is obviously more involved and can be considered as overkill for small projects.
Yeah of course. It's just I'm coming from a position where I'm pretty unsure of which solutions are better - in fact which solutions are even valid. Last few days with Ubuntu have been a bit of a roller coaster. Looking forward to deploying a sql db XD
It's definitely overkill though, you're right
I would recommend keeping things as simple as possible for now and focusing on one thing at the time. It's not like having a few extra Kb on your github repo is gonna do any harm 👍
Yeah that's definitely good advice, and I'm often guilty of over engineering things. Out of interest on that point, how would you deal with form data if you had a separate frontend? That's basically all this separate backend is doing for the time being - it's saving users and enquiry forms and acting as a login server. It's caused a lot of headaches but I've learnt a lot. I'm justifying it because of that learning, but there must be a simpler way (say if a client just wants the form emailed to them)
Well, you do you need some backend code to run in order to process user authentication, emailing, etc. There are services like Firebase or Supabase that can handle this for you, with free plans that are more than enough for small needs. For sending emails, you can use something like Sendgrid which again has a generous free-tier.
If you don't have any interest or need to handle this sort of thing, then delegating to a third party service is probably best. I personally like having control of my stuff, which is more work, but gives me the perfect excuse to practice and learning, as well as doing thing the way I prefer. Save for a few things like emails that I do not want to deal with myself as they tend to be more troublesome.
Perhaps you can do this once, and now that you know what it takes, other projects you can look into reaching out for third party services. This is actually a useful skill regardless, knowing how to handle API keys is also quite the challenge since you can't have those in a git repository, but you need to have them in the server.
Yeah, completely agree, that's exactly how I feel about having control of it too, but having built the authentication already I'm definitely not opposed to using third party services at least for the experience next time
I was more hoping that there was a simple plug and play package or service that could handle form data beyond an email input/mailto for very cheap clients/projects. But now that you mention it Sendgrid probably is great for it, although yeah, I'd still want to have a backend to protect my keys (although I guess it would be incredibly basic at that point).
Thanks for your help Joao, your advice has been 🤟