[jumpkick]

I recently revived a web app I wrote in 2006, my first startup. It was a social media site focused on media sharing. A pretty simple LAMP stack for the time. PHP 5, MySQL 3.2, but it has all of your typical (for the time) social media features. I revived this app because I wanted some hands-on time with new CI/CD tech that I don't get to use at my day job, so I'm working to extremely over-engineer the app's deployment process as a learning project. I could have used Wordpress or some other Hello World app, but this is a lot more fun.

I had written nearly all of the PHP from scratch. I wrote libraries for authentication/authorization, templating, form processing etc. I used one PEAR library for sending email. The frontend was vanilla HTML and there was barely any JavaScript to speak of. We used Flash for media playback. In other words, myself and my small team built nearly all of it ourselves. This was just how you did most things in 2006.

It only took me about an hour to get the 19-year old app up and running. I had to update the old PHP mysql drivers to mysqli, and update the database schema and some queries to work in MySQL 8 (mostly wrapping now-reserved words with backticks and adjusting column defaults which are now more strict). The only thing that didn't work was the Flash.

An hour to revive an app from 2006. Contrast this with my day job, wherein we run scores of Spring Boot apps written in Java 8 that have pages of vulnerabilities from tens of dozens of dependencies, which are not easy to update because updating one library necessitates updating many other libraries, and oh my goodness, the transitive dependencies. It's a nightmare, and because of this we only do the bare minimum of work to update the most critical vulnerabilities. There's no real plan to update everything because it's just too tall of an order.

And the funny thing is, if you compare what this PHP app from 2006 did, which had truly, barely any dependencies, to what these Spring Boot apps do, there is not a lot of difference. At the end of the day, it's all CRUD, with a lot more enterprise dressing and tooling around it.

[skydhash]

Go and the C linux world have sold me on the fat library philosophy. You brought a library to solve a problem in a domain, then add your specific bits. You don't go and bring a dependency for each item in your check list. Yes there may be duplicate effort, but the upgrade path is way easier.

[9dev]

That works until you’re sitting between two fat libraries with overlapping, but incompatible concerns. It’s tradeoffs all the way down.

[HumblyTossed]

> That works until you’re sitting between two fat libraries with overlapping, but incompatible concerns. It’s tradeoffs all the way down.

This reads like the dev equivalent of manager speak.

[ok123456]

Most of that new CI/CD tech is standard now precisely because of all the complexity added by maintaining third-party dependencies and constant changes in the runtime environment. This isn't a problem for the most part for an old LAMP application deployed by scp.

[madduci]

While I might agree with you on some points, I don't want to spend time reinventing the wheel and introduce bugs into it.

Take for example standard communication message formats like FHIR or HL7. You definitely don't want to implement the whole definitions for the standard, which is already complicated.

Writing Cryptographic functions by yourself is also typically a shot in your foot, has proved in all these years of found critical security issues.

We live in a time where you want to actual solve a business problem, by focusing on the problem and not on how the solution is built properly. With the advent of AI this is even more critical, since all the code feels like stitched together blindly.

Spending time on developing all by yourself might give you a good shot in the long run, but first you need to survive the competition, who maybe has already caught the market, by using fast and throw-away code at the beginning.

[fm2606]

> my day job, wherein we run scores of Spring Boot apps written in Java 8 that have pages of vulnerabilities from tens of dozens of dependencies, which are not easy to update because updating one library necessitates updating many other libraries, and oh my goodness, the transitive dependencies.

At my job we have a fairly strict static analysis policy and starting in April it is going to get even more strict.

Have you looked at https://docs.openrewrite.org/ to automatically upgrade your dependencies?

I just migrated from Java 8, Spring Boot2 and Swagger to Java 17, Spring Boot 3.3 and OpenApi 3. It was pretty painless.

Now, I still have update some dependencies and transient dependencies but the biggest hurdles were taken care of by the migrations.

[pie_flavor]

An important point here is that the transitive dependency issue completely does not exist in Rust. If you upgrade a crate to a version which upgrades its public dependency, i.e. it uses it in its APIs and you need to interact with it to interact with those APIs, then you obviously need to upgrade your copy of the subdependency at the same time. But private transitive dependencies are totally irrelevant unless they link to C libraries. You can have as many semver-incompatible versions of a crate in the same dependency tree as you want, and even depend on multiple versions directly if you need to. No Java-style sweeping upgrades are ever needed, just upgrade the one thing with the vulnerability. (I believe C# has the same feature, though it's a little more baroque about it.)

[kgilpin]

I’m curious if the OpenRewrite project has any value to you in keeping your Java stuff up to date?

(I’m not affiliated with it; just curious about strategies for upgrading and maintaining apps that use big frameworks.)