proj-oot-ootComponentNotes1

dependencies between plugins?

see also ootPlugInArchitecture

see also [1]

--

https://blog.nodejitsu.com/ioc-and-dependency-injection-with-broadway/

i've seen multiple ppl say that the 'lifecycle' methods such as https://facebook.github.io/react/docs/component-specs.html#mounting-componentwillmount are really useful in React (although i dont understand why):

https://facebook.github.io/react/docs/component-specs.html

---

https://en.wikipedia.org/wiki/OSGi

but " I worked with a team on a content system based heavily on DayCQ? (now part of Adobe Experience Manager) which made use of OSGI. One of the promises of OSGI is that you can download new modules or upgrade existing modules without having to restart the core system. In reality, we found this isn't always the case. Frequently it would be non-obvious what sort of module changes would require a restart, and much of the burden fell to module authors to ensure that this hot-deployment capability was retained. We felt that much of this was due to the problems associated with trying to shoehorn a module system into a platform that doesn't support it by way of a library. I really hope Java 9's Jigsaw module system will change things here."

---

java9's jigsaw

---

" The team are going to look at is how to make it easy to split the ruby application at a later date. When deciding later on to make an in-process module a separate microservice, you face two challenges. The first is separating the code cleanly, and creating a coarse-grained API that makes sense to be used over a network rather than the fine-grained method calls we may permit inside a single process. The other challenge though is pulling apart any shared persistent data storage to ensure our two newly separated services don't integrate on the same database. This last point is typically the biggest stumbling block.

To deal with this, one of our internal development teams inside ThoughWorks? decided that it made sense to map modules which they felt could at some point in the future become services in their own right to their own data schemas, as seen above. This obviously has a cost. But by paying this cost they kept their options open - pulling the service apart at a later date becomes easier as a result. The Asterix team are going to consider using the same approach within their ruby application.

The Asterix team will need to keep a close eye on the module boundaries within the main application code base. In my experience it is easy for what starts off as clear modular boundaries to become so intermingled that future decomposition into services is very costly. But by keeping the data models completely separate in the application tier and avoiding referential integrity in the database, then separation further down the line shouldn't be hugely challenging."

one POV on greenfield microservices:

" Almost all the successful microservice stories have started with a monolith that got too big and was broken up Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. . "

an opposing POV

" wellpast 2 hours ago

> 1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up.

This is pure survivor bias. The majority -- by far -- of 'failure stories' I know of in the software industry are ones in which a company tried to take their monolithic code base and modularize or microservice-ize it.

> 2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

This is not because microservices-first is inherently flawed. This is purely a skill set issue. Microservices demand a greater skill set. A 'monolithic' approach puts much less of a demand on the engineer's skill set.

For a simplistic but illuminative example, if all you know how to do is build systems that operate on global mutable state (most newbie programmers), then of course you will run a lot further in a monolith than if you are trying to do this in a microservices pardigm.

This is a simplistic example because effective use of microservices requires much more of a skill set than not using global variables. The truth is that effective use of microservices (knowing how to build architecturally sound software) is way beyond the reach of MOST smart, senior level engineers that I've met in my career. If this sounds arrogant, it's not; there's a definitive architectural skill set that CAN BE LEARNED but that is missing from most software practitioners. (Our industry/academies need to learn how to teach it.)

This is the elephant in the room in our industry--and why we spin so many wheels talking about everything else. All of the energy we spend talking about patterns, processes, languages, etc etc do so much less for our industry than if we trained our practitioners in how to construct architecturally sound software systems.

reply "

--

" Service Objects - the Enterprise Programmer(TM) approach

Enterprise Java Programmers have a concept of a Service Object. The Service Object is an abstraction for the ability to provide some functionality. Lets take email as a working example. We could potentially represent the ability to send email via the following Scala trait:

trait EmailProvider? { def sendEmail(to: EmailAddress?, from: EmailAddress?, subject: String, body: String): Future[EmailSendStatus?] }

For those more familiar with Java, this is equivalent to:

interface EmailProvider? { Future<EmailSendStatus?> sendEmail(EmailAddress? to, EmailAddress? from, String subject, String body) }

The fact that a Future[EmailSendStatus?] is returned indicates that at the time of calling the method, the result of sending may not be available. I.e., sending the email may take 250ms, but code which does not explicitly depend on the result of sendEmail can continue processing while waiting.

In Python, it would probably be:

"""Coding convention. Any object with a `send_email` class member is an `EmailProvider?`. The `email_provider` variable on all the classes in this file should be defined, take the arguments to, from, subject and body, and do the right thing. """

This trait/interface (from here on out I'll use Scala terminology) represents the capacity to send emails.

The key fact about this trait/interface is that programmers working on a team other than Team Email are forbidden from ever using any interface besides EmailProvider?. This can generally be enforced at the level of the type system. "

---

https://en.wikipedia.org/wiki/Dependency_injection

" ve. Three types of dependency injection

There are at least three ways an object can receive a reference to an external module:[7]

    constructor injection: the dependencies are provided through a class constructor.
    setter injection: the client exposes a setter method that the injector uses to inject the dependency.
    interface injection: the dependency provides an injector method that will inject the dependency into any client passed to it. Clients must implement an interface that exposes a setter method that accepts the dependency.

"


maybe we should do something like this (signals and slots and connections, and maybe a std way to do qt 'metaobject'-like stuff):

https://woboq.com/blog/how-qt-signals-slots-work.html

---

https://extism.org/blog/announcing-extism/

https://news.ycombinator.com/item?id=33816186

---