-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use PHP for Middleware Services #252
Comments
Comment by daniel-dgi 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. |
Comment by daniel-dgi 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. |
Comment by mjordan 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. |
Comment by DiegoPino 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 😄 |
Comment by btmash 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). |
Comment by mjordan 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). |
Comment by daniel-dgi This conversation makes me happy. 😍 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? |
Comment by DiegoPino @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 😄 |
Comment by daniel-dgi Adding to agenda with this pull |
Comment by ruebot Merged 😄 |
@DiegoPino @whikloj - I'd say we've addressed this one. Can we mark it as closed? |
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: |
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
Remarks:
The text was updated successfully, but these errors were encountered: