cmdobueno's avatar

A question of semantics and concepts

So, I am currently building an enterprise level software (and I have a few more additional projects of similar magnitude coming up at the end of this year)

What I am wondering is probably going to be somewhat opinionated from those that respond, but I am looking for reasons, pros, cons, and personal experience (and the honestly the language/framework means very little)

So here is my question. When building an enterprise system, that let us estimate, will have a life span of at least 5 years (not to say it will be build and sit untouched for 5+ years), is it best to use pre-built packages. Take your pick on which. The ideal goal for the package is to "kept up to date" given I understand issues with breaking changes within laravel, which can (and has).

The reason I question it:

  1. Packages, no matter how good they are at the time get outdated or abandoned.
  2. Packages sometimes just do not do "everything" you want
  3. Legalities of certain packages

Reasons I like them:

  1. They can save a boat load of time
  2. The good packages are generally very well coded

There are of course many more pro's and con's but I did not want to list everything. I am just curious about what everybody else thinks, so that I can make an educated decision in the next few weeks.

Thanks

0 likes
2 replies
ohffs's avatar
ohffs
7 years ago
Best Answer
Level 50

I build apps which generally have a lifespan of 10+ years - the current main one was build over 10 years ago and was never touched or updated and it's a monster :-(

I tend to pick PHP packages for them if it's going to save me a lot of 'fiddly' stuff and time - and if the people who wrote them seem to be fairly committed. So for instance in the 'monster' app there is a whole lot of image storage/processing and I've used the Spatie medialibrary as it does a whole lot of what I'd be implenting myself and does it well. I've also got a markdown converter and a pdf exporter in there as it's a lot of time to do yourself and PHP has some pretty mature packages for it.

For javascript though - it's a harder call. 'Mature' in javascript-land can often seem to mean 'was released more than an hour ago' ;-) I once spent a day implementing a javascript feature and by the time I'd finished the package I was using had gone through two 'major' releases and changed it's API completely :-/

It's always a bit of a judgement call - as your say - time saved vs. abandonded/customisation/etc. If I feel the need to pull in a PHP package I'm not 100% on, I'll quite often wrap it in my own 'decorator' with just the features I need exposed. Then at least if it goes away I can keep my 'business' code the same even if the underlying package has been swapped out.

cmdobueno's avatar

@ohffs

That makes a lot of sense. I will have to keep those things in mind. I mean generally speaking the who concept of using packages vs not is kind of biased, as I plan on using laravel which in the end is a "package" itself. So yes the pros vs cons concept will be very strong.

Thank you for your input.

1 like

Please or to participate in this conversation.