3 ms·

You write a library, then wrap a thin service interface around it. Distribute the lib as needed. Publish the service as needed. Maintain the library, modifying

You write a library, then wrap a thin service interface around it. Distribute the lib as needed. Publish the service as needed. Maintain the library, modifying the service on as it is affected. So this effectively comes down to “write a library” as tfa suggests. But there’s no reason the library can’t then be the core of a service.

soulofmischief 3y ago
I take "where possible" to mean that what you describe should be considered an exception instead of a rule, which I agree with. I do have some thin services which are libraries, but above and beyond directly importing libraries is preferred. With edge functions becoming more popular, this also seems to be the preferred pattern, having "fat" edge functions with shared code, vs many small edge functions calling each other.
mooreds 3y ago
> You write a library, then wrap a thin service interface around it. Distribute the lib as needed. Publish the service as needed. At $CURJOB, we did this but at a higher level of abstraction (an authentication architectural component, rather than a library). I think this is what the author means when they say "writing a standalone server reached through a network protocol". We see a lot of folks who like the flexibility of consuming functionality as a service or library, as they see fit. We've even had customers who said "we chose you because now we want you as a service, but later will want you as library" or vice versa. Flexibility isn't free, though. Versioning, support, backwards compatibility (features and performance), even offering the service all become more complex.
lenkite 3y ago
You can also start calling your library - a "distributable, embedded, natively consumable micro-service" and then other folks start using it. (Believe it or not - this is what some teams in my org started calling a traditional library)
- jagged-chisel 3y ago
  I support this use of parlance to get everyone onboard :-)

soulofmischief 3y ago

I take "where possible" to mean that what you describe should be considered an exception instead of a rule, which I agree with. I do have some thin services which are libraries, but above and beyond directly importing libraries is preferred. With edge functions becoming more popular, this also seems to be the preferred pattern, having "fat" edge functions with shared code, vs many small edge functions calling each other.

mooreds 3y ago

> You write a library, then wrap a thin service interface around it. Distribute the lib as needed. Publish the service as needed. At $CURJOB, we did this but at a higher level of abstraction (an authentication architectural component, rather than a library). I think this is what the author means when they say "writing a standalone server reached through a network protocol". We see a lot of folks who like the flexibility of consuming functionality as a service or library, as they see fit. We've even had customers who said "we chose you because now we want you as a service, but later will want you as library" or vice versa. Flexibility isn't free, though. Versioning, support, backwards compatibility (features and performance), even offering the service all become more complex.

lenkite 3y ago

You can also start calling your library - a "distributable, embedded, natively consumable micro-service" and then other folks start using it. (Believe it or not - this is what some teams in my org started calling a traditional library)

jagged-chisel 3y ago
I support this use of parlance to get everyone onboard :-)