search

Islandora / documentation

Contains islandora's documentation and main issue queue.
MIT License
104 stars 71 forks source link

Use PHP for Middleware Services #252

Closed ruebot closed 8 years ago

ruebot commented 8 years ago

Issue by daniel-dgi Friday Sep 25, 2015 at 12:49 GMT Originally opened as https://github.com/islandora-interest-groups/Islandora-Fedora4-Interest-Group/issues/38

Title (Goal) PHP for Middleware Services
Primary Actor Developer
Scope Architecture
Level High
Story As a developer, I want to be able to use a PHP web framework in order to provide middleware services that is not tightly coupled to the CMS.

Remarks:

ruebot commented 8 years ago

Comment by daniel-dgi Wednesday Oct 14, 2015 at 12:45 GMT

So I've weighed out some options. In order to effectively mimic what we're currently getting out of OSGi, it looks like using a microframework is the best option. We've got Silex, Slim, and Phalcon to choose from as the front runners for PHP microframeworks. We could also use straight Symfony 2, though I don't think that will lead to as decoupled and independent services as using a microframework to make a bunch of miniature webapps. Ideally, each service would run independently of each other, resolve it's own dependencies, and have its own configuration.

Personally, I've got experience with Silex and Symfony. Both are fine choices. Anyone used any of the others? Looks to @mjordan since I know he's used Slim.

ruebot commented 8 years ago

Comment by daniel-dgi Wednesday Oct 14, 2015 at 12:51 GMT

Also, see Chullo and Porkpie as examples of libraries that we'd be using with whatever web framework we choose to go with (if we choose to go with one).

Using PHP for this will incur a lot of code maintenance, which I was desperately trying to avoid when prototyping. If there's stronger community involvement, then we can weigh out whether or not this is worth it.

FWIW, if it gets the community involved, I think it's worth it.

ruebot commented 8 years ago

Comment by mjordan Wednesday Oct 14, 2015 at 16:19 GMT

WRT Slim, it's my goto PHP microframework. I have to admit that I haven't used a lot of other PHP microframeworks (I have used Bottle in Python for a few things), but I find Slim to be clean, efficient, and well documented. It seems to comply with a lot of standards and best practices, is a "modern" PHP library (composer, PRs, etc.) and is maintained well.

One advantage of Silex would be that it's part of the Symfony family of libraries, so it might be more future-friendly for our particular community.

ruebot commented 8 years ago

Comment by DiegoPino Wednesday Oct 14, 2015 at 16:23 GMT

I would suggest Silex for similar reasons @mjordan stated. If Silex is too "slim" then moving from silex to Symphony it's an option that does not involve too much additional coding. Also, thinking in Drupal8 folks and future, it makes integrating or reusing simpler (i think). But i also find SLIM nice :smile:

ruebot commented 8 years ago

Comment by btmash Wednesday Oct 14, 2015 at 17:12 GMT

So long as the core library behind it is PSR-4 compliant, someone building it into their web framework of choice shouldn't be a big issue (see work by Commerce Guys on addressing (at https://github.com/commerceguys/addressing) that, because it is a PSR-4 compliant library, can be used in any modern PHP framework (they are using it in D8 and Silex projects, I believe). I think Silex is a good option for a micro framework. There is huge community around it and, if we are still specifically using Drupal for a lot of this, would be beneficial in pulling over people familiar with D8 development (Silex + Drupal is a fairly common pairing). If you want something more than that, you could go down the Symfony CMF route or possibly even Laravel (the codebase is pretty fantastic, it has a large community, and uses Symfony components).

ruebot commented 8 years ago

Comment by mjordan Wednesday Oct 14, 2015 at 17:19 GMT

Using Silex makes a lot of sense given its relationship to Symfony and Drupal 8. I'm glad to hear from people who have used it (as I stated, I haven't).

ruebot commented 8 years ago

Comment by daniel-dgi Wednesday Oct 14, 2015 at 18:00 GMT

This conversation makes me happy. :heart_eyes:

I'd like to back up @btmash here. Choosing the web framework is important, but it's more important to use PSR-4 and composer for shared library code. If properly architected, it'll fit into any web framework, especially one with a DI container. In fact, it'll also fit into any CLI framework too, which will help mitigate the loss of Drush and work nicely when we want to start doing multi-threaded ingests and sync machinery. Can you imagine an islandora where code re-use resulting in multithreaded ingest is a standard feature?

Y'all think this is worth adding to the IG meeting agenda, and hopefully voting on?

ruebot commented 8 years ago

Comment by DiegoPino Wednesday Oct 14, 2015 at 18:26 GMT

@btmash++, PSR-4 and composer is the key for reusing and cross integration. A happy @daniel-dgi is also a perfect result of this conversation :smile:

ruebot commented 8 years ago

Comment by daniel-dgi Thursday Oct 15, 2015 at 18:50 GMT

Adding to agenda with this pull

ruebot commented 8 years ago

Comment by ruebot Thursday Oct 15, 2015 at 21:38 GMT

Merged :smile:

ruebot commented 8 years ago

@DiegoPino @whikloj - I'd say we've addressed this one. Can we mark it as closed?

ruebot commented 8 years ago

Closing this as we have addressed this. We have moved away from the 7.x-2.x branch, where all the microservices were done in Java. The master branch has them all done in PHP now, and recently has been broken out into their own projects, as well as published on packagist: