Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save phillipsharring/e0fd9dc9b5e521db9b109c2aaa815696 to your computer and use it in GitHub Desktop.
Save phillipsharring/e0fd9dc9b5e521db9b109c2aaa815696 to your computer and use it in GitHub Desktop.

#Middleware in Laravel 5

Middleware is a powerful feature of Laravel 5. In this talk, we'll briefly cover what middleware is, it's place in the Laravel lifecycle, and how to create it. Then we'll look at some real-world, in-production use cases that demonstrate the appropriate use of middleware to examine incoming requests, and situations where you might modify the out-going response headers or body content. Finally, you'll learn some use-cases where not to use middleware, and how to test it. Phillip is a web developer with 16 years of experience currently building solutions with Laravel for Cisco Systems, Inc.'s Learning@Cisco team.

@phillipsharring
Copy link
Author

phillipsharring commented May 27, 2016

Added a quick bio - is that appropriate?

@chrisseaton
Copy link

I think a problem with this abstract is that I could have guessed everything in it. You say you're going to what this thing is, what its place is, how to create it. Then we'll look at some use cases, and situations where you might want to use it. Then we'll see where not to use it, etc.

This is all stuff that I could have guessed you would talk about in a talk about almost any technology.

Do you want to talk at all about why I would be excited about learning about this tech? I think you need to say something about why it's useful. At the moment this abstract is a bit like a bullet point for the talk, but an abstract needs to be a pitch. Why should I care about Laravel and why should I come to your talk?

@wenz
Copy link

wenz commented May 27, 2016

If I was using Lavarel, I might be interested in this talk, especially since you also mention disadvantages which is quite rare (but very welcome). I do agree with Chris that you need to pitch the topic more. Maybe a catchier title? Or mention why exactly middleware is a "powerful feature" (or maybe even mandatory)? Or better use cases (as far as I can read from the abstract, you just work with the request and the response, which kinda is the same case)?

Also, do remove the bio. Most conferences have a separate field for that in their call for papers. The bio doesn't help the abstract.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment