You’re looking at this correctly. This is a big issue with all package managers, node and others suffer from the same kinds of issues. GitHub has dependabot that will routinely scan for vulnerable packages, and you can do similar things on your own to try and mitigate the risk. There was a suggestion about using something like Symphony where it doesn’t draw from as many dependencies. This seems like good advice, but it might be going too far as I work with projects with much higher package counts and they are considered secure.
Doug Hatcher
Enterprise architecture and tech junkie
Posts in r-php category
I agree with the sentiment that it’s your course to set and the major consideration is your own personal sanity. I will say, however, that if your project is used by many projects then one consideration should be their adoption strategy. Maybe it makes sense to find some usage stats, or maybe a survey, and figure out what versions of PHP your users are currently using and expect to use throughout the course of your roadmap.
Honestly, just do your best and learn to be a good teammate. Languages come and go, and with ChatGPT you’ve got a buddy ever ready to answer questions. My advice is use it, don’t rely on its code but use it to grok and understand. The rest is being useful. Ask the dumb questions, because you’re not the only person wondering. Give practical commitment dates, over communicate and help those around you.
How big is the codebase? Obviously you’re facing a rewrite, but I would start by reviewing the logs and codebase, think deeply about how it should work, and isolate the current solution and mitigate the problems while you start building the correct solution.
You need to begin by getting your arms around the biggest problems and begin to address them this week. Start by installing new relic, tackle problems with zeal, and do it first on a staging environment with plenty of testing so you’re not introducing more problems.
I’ve found it’s best to shoot from the hip. If they are as big as they claim (and in the US), they’re expecting to pay out the nose. Also, keep in mind that HR is separate from the development side of the house (even if they have developers conducting interviews) and they’re also likely under the gun to find good hires. All of this plays to your advantage. I think the best play is to generally shoot high and see how they roll with it.
Generally, I think you should build docker images and perform testing and linting against those using the functionality of the pipeline of your favorite git service. You can then trigger deployments with services that leverage docker images, and you feed it the same build images you were testing for deployments. Different applications have different deployment details, but whatever the application, if you can dockerize it then you can generally roll it out with little to no downtime, and it’s usually fairly portable to other services at that point too.
Inheritance is a good way to give objects common functionality while changing key pieces to suit different purposes. For example, you can define an interface that describes how data flows through your application. Then you can write an abstract class with the database plumbing. Then maybe you’d create a posts class to represent a collection of posts, and that class is where you’d store the logic specific to posts. In this model, there is no code duplication, and you’re using interference to share code across multiple objects that largely work the same.
You really have to appreciate his integrity, likely not an easy post for him to write. Still, it seems like an official GraphQL implementation would be prefered, and you could sunset a lot of the REST functionalities while fleshing out an API more suited for headless content management and delivery. I say merge it anyways!
www.reddit.com/r/PHP/com…