Hacker News Reader

> If you're using python for the web you're already part of the complexity problem, atleast from the perspective of someone deploying php 15 years ago.

The problem with deploying PHP is that it immediately gives you something for very little effort, but the effort scales incredibly disproportionately once you outgrow your need for the bare functioning minimum.

I personally prefer the "modern" approach of dropping a single, statically compiled binary, which exposes a listening HTTP socket. In case of Go or Rust+Actix, this could sit directly on port 80, but as soon as you add HTTPS, ACME, virtual hosts, etc the story is basically the same regardless of language/framework choice, PHP included.

Oh I agree, I still get chills when I think about troubleshooting PHP.

I was really just making the point that the effort to deploy python as a webapp these days would have been considered overly complex to the average developer 15 years ago. Just how some of the current stuff seems to the OP, so maybe not all seemingly complex stuff is bad.

The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control.

Fair enough, but I was thinking more along the lines of debugging logic. With python I can open up a local repl or jupyter, run the affected functions/methods, and from there I can get a nice traceback, modify code, or monkey patch something to figure it out. If I can't reproduce the bug locally, I can run a repl directly on the server to see how the code runs differently.

My frustration with PHP is just memories of making an edit, refreshing the page, and crossing my fingers. Then once it's working forgetting to save it anywhere else because there wasn't a repo to begin with. I know the tooling has got much better, and PHP developers actually use deployment pipelines these days, and it was mostly caused by myself, and my co-workers not knowing any better. Still just how I remember it. And I don't think I'm the only one.

Fair enough as well, but the internet seems full of people who’ve used php decades ago, and spread falsehoods based on that as fact. Your REPL complaint specifically is void these days - you can do exactly the same with a php interpreter, there’s kernels for Jupyter, tracebacks, repl locally and in any production environment (readline is baked in).

It’s incredibly frustrating to see people discuss the language without any actual knowledge of it. Modern php involves one of the most stable package managers of any language, an extremely fast runtime with a JIT compiler and opcode cache, asynchronous code and coroutines (well, native green threads at least, but proper coroutines via an extension), mature frameworks, stateful application servers, solid standards among frameworks, containerised stacks,… it’s a joy to work with, yet people complain about standard library function names and form handling in templates from 1999.

This is why you shouldn't run Python in your downloads directory:

    python3 -m http.server 8000

Concepts of "app" have changed and superstitious ritual has built up around the sacrament of deployment.

If you're running malicious code it doesn't matter which directory you're running it from.

And I hope noone is using http.server to deploy their python webapps. the documentation even has a warning right at the top

https://docs.python.org/3/library/http.server.html

When did you last use PHP? It's not the PHP of 15 years ago. It scales fine when properly written and deployed.

I didn't mean scalability in terms of performance, but scalability in terms of maintenance effort. It's easy to SCP some files in, but the moment you want atomic deployments, it gets unnecessarily interesting.

Atomic deployments with PHP is basically as simple as "git pull" in a temporary working directory and copying it to a release directory..

for your "personal blog" git pull can be used as deployment - don't forget to exclude the access to the .git directory in .htaccess ...

but for "serious" applications / deployment-routines this is never an option ... you have to use some kind of deployment & configuration mechanism.

PHP is the only language I've set up production environments for, but I can't see any reason why it would be more complicated than other languages.

I have a PHP project that handles atomic deployments by pointing the web server at a symlink named "latest". New versions get deployed into their own folder in the "versions" folder, and then the "latest" symlink gets pointed to the new version. Super simple to set up, and as long as you delete old versions as you go (keeping, say 3 versions so you can roll back as necessary) that's pretty much all there is to it. This all gets triggered by a Gitlab CI workflow, so I can hit a button to deploy after merging changes.

Another PHP-focused way to handle this would be deploying into a new folder, then updating the nginx config to point to that folder and running `service nginx restart`.

You can also use one of the many other atomic deployment options that replace more than just the running code, at which point the only difference between deploying a PHP webapp and deploying a Java/Go/Rust webapp is what gets included in your new server/container when you build it.

That's my entire point: the increase in complexity is very non-linear. With Python, Go, or whatever else, you pay a slightly higher upfront price, and you get things like atomic deployments out of the box; that price is however almost immediately amortised by the de-facto requirement to set up HTTPS/ACME, etc.

With PHP it's easier to just get started, but you've already mentioned versions, symlinks, CI, etc - that's the non-linear increase in complexity, you have to add a lot more pieces to get good ROI. With Python or Go you can continue using SCP to deploy for as long as it suits your needs, because no code changes will be picked up until you restart the process. If you need rollbacks, e.g. Go doesn't need symlinks or versioned directories - the entire app is a single executable, so you can just keep copies of these. You pay for what you use, and the returns are more linear and immediate.

If you only have experience deploying PHP, I would sincerely recommend trying other languages/runtimes/frameworks, even if for no other reason than to learn from what the rest of the world is doing. For me, learning to deploy PHP correctly was also a horizon-broadening experience.

Regardless of how you're deploying things, having unrelated projects in the same git repository might be simpler (maybe?) but certainly seems worse at the same time.

Regardless of how you're deploying things, having unrelated projects in the same git repository might be simpler (maybe?) but certainly seems worse at the same time.

Sure, if they're actually unrelated, or being managed by separate teams then split it up. Though I think the default should be to have one, and split it when there is an actual reason to, especially if it's for the same project.

The example I gave wasn't an exaggeration, 14 repos for one project. It was originally built and managed by one person who had them all in the same directory and would open them all in his IDE at once and basically worked on it as a mono repo. After that person quit, when others needed to figure out which repo to clone to fix things it was a nightmare.

I know monorepos can be extreme like google, but I just mean one per team, or at least one per project. You shouldn't have to worry about versions of your libraries when there is only one project using those libraries.

Edit:

For example, a project I did the layout for has a python backend, with a spa frontend, and some ansible playbooks for deployment, integration tests, and a few libraries only used by this project.

Each of those 5 things has a top level directory and we deploy a test server for every branch, plus most of us run a local server. We never have to worry about versioning between our own projects, because if they're in the same branch that's the version to use. If we split it into separate repos, then everytime we added a new field to the api, and needed to update the frontend and tests, we would have to manually specify which versions of all the repos go together to build a test server, or to even run a local dev server.

i'm wondering what engineering decisions drove the project to be split in 14 parts?

is it like micro-services thing or what?

Yes it was mostly micro services, with a separate frontend repo, and a separate repo for deploy scripts, some separate libraries that were shared between the microservices, there may have even been a separate repo for documentation, I don't remember exactly.

I think it really just came down to dividing the repos into chunks that the deployment scripts could use/trigger off of. Instead of developing in a way that makes sense for developers and bending the deployment to fit. Since it was all in one directory on his computer, it was basically a mono repo from his perspective. Committing from the IDE just committed to whichever repo was changed, and since he was the only developer he never saw the downside. When I had to take it over ghorg[0] really came in handy. It's a script to clone all repos from a user/organization on gitlab, github, and others. Then once I opened up all the repos as one pycharm project I was able to get some stuff done, but at that point I might as well just had one repo with a separate directory for each.

[0]https://github.com/gabrie30/ghorg

EDIT: I also just remembered that gitlab is much better than github if you are going to go the route of multiple repos for one project. Gitlab lets you create namespaces to group your repos, so if they're all in the same namespace, you could have documentation to just tell people to clone all of them.

> Sure, if they're actually unrelated, or being managed by separate teams then split it up

What if they become managed by separate teams? Or two projects in separate repos become managed by the same team? What about a service that basically everything else in the company relies on (for Google, accounts and auth for example).

Better to just keep things in a monorepo IMO, even if they seem unrelated.

What if they become managed by separate teams? Or two projects in separate repos become managed by the same team? What about a service that basically everything else in the company relies on (for Google, accounts and auth for example).

Better to just keep things in a monorepo IMO, even if they seem unrelated.

If there are multiple teams committing to the same repo you need controls over who has permission to commit to which directories and maybe a policy for handling merge conflicts across teams. I'm not sure what the tooling is like around that, but I could see the benefits as long as someone very high up was on board and had enough of a technical mind to keep order.

As far as two repos becoming one or one repo becoming two, you can split and merge repos while keeping the commit history.

edit: Do you have experience working somewhere with a monorepo that stretched across multiple teams? if so, what was it like?

> As far as two repos becoming one or one repo becoming two, you can split and merge repos while keeping the commit history.

I don't have experience doing that but it sounds like a huge headache to me. Any tooling, deployment processes, links in documentation, cross-repo references etc would need to be updated right?

The company I was in before my current one used a mono-repo for the whole company, I thought it was pretty great! We had ~150 engineers, so not Google-scale but still many individual teams and services. Similar to the Google strategy, a pull request / code review would be against master, and then it would be merged directly to master. The tooling would automatically rebase your change on master before merging. Deployment would happen automatically or manually (the team could decide) and would be pinned to a git commit hash. If automatic, the CI tool would detect if there were any changes to your binary that required deployment (so a totally unrelated PR would not trigger a deploy). You could manually deploy an older commit hash if you wanted.

Why does it seem worse? This is perhaps just each of our individual biases and values hiding behind a preference but I can't identify an objective reason why it's worse other than Jenkins or devtool of choice not handling it out of the box.

Don't get me wrong. CI/CD and other dev tools not handling monorepos well is a totally reasonable objective reason to not use monrepos. But it's also mostly about the tool not the monorepo concept itself.

In the last year, there has been a concerted push by certain influential engineers to split our mono repo up. This was first done by splitting things into two repos that were supposedly independent. But they really weren't. Naturally, there was code and configuration that we wanted to be common between the two repos. So now, the solution to every one of these problems is to break off more code its own repo. As the saying goes, as soon as you have two objects, soon you will want a third. It has become a complete nightmare to work with, and as far as I've seen so far has had zero tangible benefits.

> If you're using python for the web you're already part of the complexity problem, atleast from the perspective of someone deploying php 15 years ago. [...] deploying webpages used to be copy an apache config and ftp/scp your files to some location.

There is a MASSIVE difference in the value proposition of a proper deployment from version control and using something like docker w/ docker-compose to facilitate running your project locally (which is not present in your PHP example) versus what the OP is talking about, which is the idea that you should run EVERYTHING on Kubernetes and write Rust for CRUD apps.

I mean I tend to agree now, but I don't know how I'll feel in 15 years, I certainly felt much different 15 years ago.

I have just finished three years of beating a department of 50 developers into breaking up a fifteen year old mono-repo. The rewards have been quite considerable.

Mono repos come with a particular challenge: If you have five projects {A,B,C,D,E} in the same mono-repo, you definitely do not want to be building B,C,D and E every-time someone commits code to project A! This is unimportant at small scales, but as the team grows, building and continuously deploying 'all the things' on every commit just doesn't work out.

So the first naive solution is say "we can enumerate all the things that need to be built for project A". This rapidly breaks down when someone figures out they can abstract a shared dependency for A,B and D into some other part of the mono-repo.

So now we enter build dependency tools, first Make then some other flavour, then we jump straight to Bazel because someone read about it in a Google publication, then to some custom build scripting because Bazel didn't do this hyper-specific workflow thing someone wanted... In the end maintaining a mono-repo build process becomes a hyper-specialised job function that is almost always kicked to the wayside.

In small companies, fewer developers than you can count on your fingers, or truly huge Googles that have their own VCS flavour, it can be shown to work well: But I have yet to hear a story of something in the middle succeeding with a mono-repo.

I work for a company with about 1000+ engineers that run a Bazel + Git + GitHub monorepo. As with all workflows it has its painpoints, but I am quite fond of it. It only needs a team of 8 to maintain all the integrations and performance optimisations.

GitHub is taking the problems of monorepo user's seriously (https://github.blog/2021-03-16-improving-large-monorepo-perf...) and have been responsive to the bugs and poor performance that monorepo's typically cause and exercise.

Monorepos solve the problem of cross-project "externalities" (sarcasti-quotes) like cross-project testing and CI/CD commonalities.