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!
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!