Current CTO exploring entrepreneurship on the side; coach; mentor; instructor.
Dedicated to promoting digital literacy and ideological diversity in tech.
We've abstracted an in-house framework using common elements and base classes and made them available through a dependency package.
We simply initialize the core framework product, add our package as a dependcy, and then wire up the chunks of functionality we actually need. All of this is done through basic service configuration using dependency injection, and takes maybe 20 minutes.
Software Engineer and jack-of-all-trades, mostly working with machine learning and AWS.
Interested in the trends in tech and working out how we can use them!
Current CTO exploring entrepreneurship on the side; coach; mentor; instructor.
Dedicated to promoting digital literacy and ideological diversity in tech.
Not long. We use PHP, so we included the base classes as a composer dependency (npm for JavaScript).
PHP support traits, which means we can quickly attach chunks of functionality to our base classes.
For example, our database entities all have a date_created and date_updated fields. Instead of having to touch these for every entity, we can simply add our "Dated" trait from our base package and now all the getters/setters and date management functionality is included out of the box.
We also do this for bigger things like user management, firing webhooks, sending emails, etc.
Whenever we have shared common functionality between our services we add it to the base package and it becomes instantly available to all developers in the company.
Software Engineer and jack-of-all-trades, mostly working with machine learning and AWS.
Interested in the trends in tech and working out how we can use them!
Interesting - so when you abstract out this common functionality do you find there can be much bloat in the packages that you’re creating? Lots of unused methods etc?
I’m thinking of how we could implement something like this, wrapping it up like some helper libraries we’ve created in the past but we’ve always ended up ballooning the scope of each lib
Current CTO exploring entrepreneurship on the side; coach; mentor; instructor.
Dedicated to promoting digital literacy and ideological diversity in tech.
This is for our backend projects, so package size typically isn't so much an issue.
Additionally, our use of dependency injection patterns makes our services fairly efficient.
From a use perspective, we typically only include functionality that is shared amongst all of our other Microservices. We've purposely designed our applications to promote interoperability.
Software Engineer and jack-of-all-trades, mostly working with machine learning and AWS.
Interested in the trends in tech and working out how we can use them!
We've abstracted an in-house framework using common elements and base classes and made them available through a dependency package.
We simply initialize the core framework product, add our package as a dependcy, and then wire up the chunks of functionality we actually need. All of this is done through basic service configuration using dependency injection, and takes maybe 20 minutes.
Very cool - we'd glanced at GitHub's packing tools but not given it a proper consideration - how long did it take you to get to that as your solution?
Not long. We use PHP, so we included the base classes as a composer dependency (npm for JavaScript).
PHP support traits, which means we can quickly attach chunks of functionality to our base classes.
For example, our database entities all have a date_created and date_updated fields. Instead of having to touch these for every entity, we can simply add our "Dated" trait from our base package and now all the getters/setters and date management functionality is included out of the box.
We also do this for bigger things like user management, firing webhooks, sending emails, etc.
Whenever we have shared common functionality between our services we add it to the base package and it becomes instantly available to all developers in the company.
Interesting - so when you abstract out this common functionality do you find there can be much bloat in the packages that you’re creating? Lots of unused methods etc?
I’m thinking of how we could implement something like this, wrapping it up like some helper libraries we’ve created in the past but we’ve always ended up ballooning the scope of each lib
This is for our backend projects, so package size typically isn't so much an issue.
Additionally, our use of dependency injection patterns makes our services fairly efficient.
From a use perspective, we typically only include functionality that is shared amongst all of our other Microservices. We've purposely designed our applications to promote interoperability.
Sounds really sustainable, this seems like it'll be a longer-term goal for us but could have some big payoffs,
Thanks for sharing!