Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Jonathan Reinink Software developer from Canada. Been writing PHP for over 15 years. Marketing agency for over a decade. Started contract development this year. I <3 open source.

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

We're in the middle of a PHP Renaissance.

Slide 5

Slide 5 text

We're seeing a huge shift to creating smaller pieces of focused, reusable "framework agnostic" code.

Slide 6

Slide 6 text

What exactly does framework agnostic mean?

Slide 7

Slide 7 text

Code that works independent of frameworks.

Slide 8

Slide 8 text

It’s about interoperability.

Slide 9

Slide 9 text

Framework agnostic does not mean framework intolerant.

Slide 10

Slide 10 text

Why is framework agnostic code important?

Slide 11

Slide 11 text

Framework agnostic code allows you to choose the best library for the job.

Slide 12

Slide 12 text

"You should be using best of breed stuff, you shouldn't have to use the stuff that came with your framework if there is better stuff out there; it should just drop in.” — Rob Allen

Slide 13

Slide 13 text

Framework agnostic code is also more reusable than framework specific code.

Slide 14

Slide 14 text

Reusable code is code we don't have to write.

Slide 15

Slide 15 text

Creating reusable code is key to the continued success of PHP.

Slide 16

Slide 16 text

As software become increasingly more complex, our reliance on existing, quality code increases.

Slide 17

Slide 17 text

We’re seeing a future where the various PHP communities actively share code with one another.

Slide 18

Slide 18 text

So, why then are we using framework specific code?

Slide 19

Slide 19 text

Because we sort of had to.

Slide 20

Slide 20 text

PHP was first released in 1995.

Slide 21

Slide 21 text

PHP had a decent standard library, but pieces were missing.

Slide 22

Slide 22 text

Routing Templating Database Abstraction Validation Session Handling Error Management Authentication Caching Request Processing Responses Sending

Slide 23

Slide 23 text

Developers starting writing new, focused PHP libraries.

Slide 24

Slide 24 text

But…we had no easy way to share them.

Slide 25

Slide 25 text

So we manually downloaded zip files.

Slide 26

Slide 26 text

Introducing PEAR: PHP first attempt at a package manager.

Slide 27

Slide 27 text

But…PEAR had some issues.

Slide 28

Slide 28 text

The community gave up on PEAR, and started using frameworks instead.

Slide 29

Slide 29 text

Frameworks were easy to download, and they just worked.

Slide 30

Slide 30 text

Frameworks came with almost everything needed for the average project.

Slide 31

Slide 31 text

Frameworks allowed us to get work done quickly.

Slide 32

Slide 32 text

2005 became the year of PHP frameworks. Symfony, CakePHP, Solar, Agavi, ezComponents

Slide 33

Slide 33 text

However, frameworks were only a bandaid solution to the code sharing problem.

Slide 34

Slide 34 text

What if the framework didn't have some other functionality you needed?

Slide 35

Slide 35 text

Naturally, frameworks grew to accommodate a wide range of use cases.

Slide 36

Slide 36 text

We continued to download zip files. :(

Slide 37

Slide 37 text

This led to very distinct siloed micro communities within the larger PHP community.

Slide 38

Slide 38 text

Then things changed.

Slide 39

Slide 39 text

1994 - 2004: 2005 - 2012: 2013 - Future: Vanilla PHP Frameworks Packages

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

Unlike PEAR, Composer got a LOT of things right.

Slide 42

Slide 42 text

Downloaded packages. Resolved their dependencies. Autoloaded classes.

Slide 43

Slide 43 text

Composer was an overnight success, and became mainstream in 2013.

Slide 44

Slide 44 text

Packagist, the official Composer package repository, now serves well over 100 million package installs per month.

Slide 45

Slide 45 text

Developers benefit from faster release cycles and a wealth of packages to choose from.

Slide 46

Slide 46 text

Composer gave us more than easy package installation, it also gave us interoperability.

Slide 47

Slide 47 text

Composer let us cherry pick code (packages) without all the pain of downloading zip files.

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

“We're a group of established PHP projects whose goal is to talk about commonalities between our projects and find ways we can work better together.” (PHP-FIG goal)

Slide 50

Slide 50 text

Their very first recommendation was an autoloading standard called PSR-0.

Slide 51

Slide 51 text

The PHP-FIG continues to develop standards that make framework agnostic code more possible.

Slide 52

Slide 52 text

namespace Psr\Log; interface LoggerInterface { public function emergency($message, array $context = []); public function alert($message, array $context = []); public function critical($message, array $context = []); public function error($message, array $context = []); public function warning($message, array $context = []); public function notice($message, array $context = []); public function info($message, array $context = []); public function debug($message, array $context = []); public function log($level, $message, array $context = []); }

Slide 53

Slide 53 text

PSR-7: HTTP message interfaces.

Slide 54

Slide 54 text

$_SERVER $_GET $_POST $_FILES $_SESSION $_COOKIE

Slide 55

Slide 55 text

$response = (new Response()) ->withStatus(200, 'OK') ->withHeader('Content-Type', 'application/json') ->withBody($body);

Slide 56

Slide 56 text

Expect to see more of PSR-7 in 2016.

Slide 57

Slide 57 text

www.php-fig.org

Slide 58

Slide 58 text

So, do we still need frameworks?

Slide 59

Slide 59 text

In the time of packages, the purpose of frameworks is changing.

Slide 60

Slide 60 text

“A huge part of the PHP Renaissance has been due to the advent of Composer, which has simplified dependency management, and led to tens of thousands of standalone libraries and packages.” (continued)

Slide 61

Slide 61 text

“As such, frameworks, while still popular, are often being eschewed for homemade, application-specific frameworks made of commodity components. Frameworks simply cannot ignore this trend, and decoupling should become the norm going forward.”

Slide 62

Slide 62 text

Frameworks no longer have to be everything to everyone.

Slide 63

Slide 63 text

“Frameworks dictate architecture, handle your bootstrapping and essentially give you a set of lines to color inside.” — Phil Sturgeon

Slide 64

Slide 64 text

Frameworks are now the glue between reusable framework agnostic packages.

Slide 65

Slide 65 text

Need something your framework doesn’t offer? No worries, just: > composer require the/package

Slide 66

Slide 66 text

Even frameworks are now being built using framework agnostic code.

Slide 67

Slide 67 text

“Today, even competing frameworks make liberal use of each other’s components, because the PHP community at large has adopted a culture of sharing and of working together.” — Heroku (blog)

Slide 68

Slide 68 text

Don’t be afraid to pull in components from other frameworks.

Slide 69

Slide 69 text

We’re seeing an increase in framework specialization.

Slide 70

Slide 70 text

"You will probably see more use-case specific skeletons come into the Zend Framework world.” — Rob Allen

Slide 71

Slide 71 text

"Lumen 5.2.0 marks a shift to exclusively focusing on stateless APIs with Lumen for better definition between two frameworks.” - Taylor Otwell

Slide 72

Slide 72 text

What will happen to bundles/plugins/ modules?

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

Puli aims to replace "bundles", "plugins", "modules" and similar specialized packages of different frameworks with one generic, framework independent solution.

Slide 75

Slide 75 text

puli.io https://www.youtube.com/watch?v=nRqwGGROvfw

Slide 76

Slide 76 text

How to choose a framework agnostic package.

Slide 77

Slide 77 text

Don't reach for the framework specific package first.

Slide 78

Slide 78 text

Look for packages with an existing track record.

Slide 79

Slide 79 text

Beware of the framework specific wrapper package.

Slide 80

Slide 80 text

Learn to write simple service providers.

Slide 81

Slide 81 text

use Illuminate\Support\ServiceProvider; use Services_Twilio; class TwilioServiceProvider extends ServiceProvider { public function register() { $this->app->singleton(Services_Twilio::class, function ($app) { return new Services_Twilio( env('TWILIO_SID'), env('TWILIO_TOKEN') ); }); } }

Slide 82

Slide 82 text

How to create a framework agnostic package.

Slide 83

Slide 83 text

Remove all framework specific dependencies.

Slide 84

Slide 84 text

// Framework specific $value = str_contains($haystack, $needle); // Framework agnostic $value = strpos($haystack, $needle) !== false;

Slide 85

Slide 85 text

{ "name": "your-awesome/package", "require": { "illuminate/support": "^5.2", } }

Slide 86

Slide 86 text

Don’t over commit, focus on doing one thing well.

Slide 87

Slide 87 text

Use abstractions and existing interfaces wherever possible.

Slide 88

Slide 88 text

File system: Flysystem Intervention GD ImageMagick Image processing: Local Azure AWS Dropbox FTP SFTP Memory Rackspace

Slide 89

Slide 89 text

HTTP Messages: Logging: DI Containers: PSR-7 PSR-3 container-interop

Slide 90

Slide 90 text

$server = League\Glide\ServerFactory::create([ // File system abstraction 'source' => new Filesystem(new Local('path')), // Image processor abstraction 'driver' => 'imagick', // HTTP messages interface (PSR-7) 'response' => new PsrResponseFactory( new Response(), function ($stream) { return new Stream($stream); } ), ]);

Slide 91

Slide 91 text

Offer framework specific support for your package using service providers.

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

No content

Slide 94

Slide 94 text

{ "name": "league/glide-cake", "description": "Glide adapter for CakePHP", "require": { "cakephp/cakephp": "^3.0", "league/glide": "^1.0" }, "require-dev": { "phpunit/phpunit": "^4.0" }, "autoload": { "psr-4": { "League\\Glide\\": "src/" } } }

Slide 95

Slide 95 text

If you’re a maintainer of a framework specific package, please consider making it framework agnostic.

Slide 96

Slide 96 text

It’s good for package maintainers. It’s good for other developers. It’s good for frameworks. It’s good for PHP.

Slide 97

Slide 97 text

Thanks! Follow me on Twitter at @reinink. Rate this talk https://joind.in/16658.