dwjobling
commented
4 years ago I've been following the recent exchange. In my experience, even with selecting the most likely and most popular components there is a high probability that it won't be usable as-is for any one instance. But there remains value in having OnPre and so I'm inclined towards option 2. This is also an excellent opportunity for other contributors.
For the implementations we have we should review them and caveat them for use. I'm sure there is a good use case for FileDB somewhere (3rd party configuration?) but a MySQL option may be more useful as an implementation example. We should remove the ones that are simply not implemented or implement them.
guilhermeluizsp
Liquid.OnPre is a implementation of Liquid abstractions for an on premises deployment.
Currently, while the project exists and some implementation was made, as we can see from issues such as #95 , #96 and #97, they are pretty raw.
My question is: do we need it? Are there projects using this implementation?
If so, then, what is the proposed architecture for that deployment? FileDb certainly shouldn't be used in production (or anything other than the simplest of tests, as we can see from #95), and messaging is simply not done.
The fact of the matter is that while on Azure, AWS and Google there is usually a single option for each of the services needed, on premises the number is vast. One could be using CouchDb, MongoDb, RavenDb etc. for NoSQL storage, WMQ, RabbitMQ, ApacheMQ etc. for messaging, and god knows how many APM solutions.
Therefore, I think we could either:
Forgo providing OnPre and let customers provide their own implementations, when desired. That would render Liquid less effective on on premises scenarios, but saves us a lot of work maintaining those components.
Decide on a recommended architecture for an on premises deployment, and provide components for that. This means dropping a number of implementations done and providing more solid ones.