Laravel 5 Middelware implementation about conditionalrequest

[fideloper]

Nope, this is deader than dead and does it wrong in any case I think?

The underlying symfony http classes I think takes care of all this if I
remember correctly. It's been too long to really remember right lol
On Tue, Sep 22, 2015 at 11:01 Andreas Heiberg [email protected]
wrote:

Hi,

Any thoughts on updating this for Laravel 5 with a middelware?

I'm gonna pull it down later tonight and play with it, so might send a
pull :)

—
Reply to this email directly or view it on GitHub
#2.

[andheiberg]

Hmm what do you mean it does it incorrectly?

Seemed good to me.

But I've only ever implemented E-Tag once and I was grasping back then, and it's been a while haha, so I might have missed some nuance :)

[fideloper]

It's mostly bad memory on my part. I think symfony just does it better.
Since that's built into symfony, is trust that code more.

That doesn't mean it's not a good candidate for a middleware though!
On Tue, Sep 22, 2015 at 11:14 Andreas Heiberg [email protected]
wrote:

Hmm what do you mean it does it incorrectly?

Seemed good to me.

But I've only ever implemented E-Tag once and I was grasping back then,
and it's been a while haha, so I might have missed some nuance :)

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[andheiberg]

Do you have any good documentation on the Symfony features you use for your laravel projects now?

Looking at Symfony HTTP caching now, but seems rather broad. Any help would be appriciated :) thanks man!

[fideloper]

It is unfortunately really broad (as are the docs for Symfony!)

Looking back at the code here, this might actually be usable, ha. I never used it in production, so there could definitely still be bugs and weirdnress. For example, I don't think I have an example of using an Eloquent model to generate an eTag to compare and help decide what the HTTP response should be.

(Altho it's semi-nice to get Eloquent to generate an eTag for itself).

I think what I was referring to with Symfony doing some of this for you is illustrated here - basically it helps answer the question "Was this resource modified since it was last requsted?": http://symfony.com/doc/2.0/book/http_cache.html#index-10

[andheiberg]

Yeah it would be kinda neat to have eloquent autogenerate eTag's, but it's only really a solid implementation for the most basic CRUD api controllers as I think through it. idk.

So when it comes down to it E-Tag's only really seem useful for:

• Saving bandwith
• Saving processing, but most of the time data retrial is the expensive part?
• Saving view generation

I'm trying to think of ways to reduce the amount of computation needed to generate the e-tags. But I guess effectively you will always need to fetch the resources. Unless you build a map of dependencies so you could store e-tags in an app cache and invalidate them when a dependency changes.

Have to give it some more thought, but for most applications I work on it seem's like little gain is achieved.

Immediately I was looking for a solution to invalidating my client cache when the api data has been changed.

[fideloper]

Yeah, man this reminds me of the circus I did getting all this in my head
as well. You end up doing all the database querying no matter what, so
while in theory you'd like to save server computation/network calls, you
don't!

Unless you do some caching scheme where you can query an md5 hash or etag
of a resource and update that when a resource is updated. Then in theory
you're querying a fast cache instead of a relatively slow database call.

The internet is a complex place!

On Wed, Sep 23, 2015 at 8:16 AM Andreas Heiberg [email protected]
wrote:

Yeah it would be kinda neat to have eloquent autogenerate eTag's, but it's
only really a solid implementation for the most basic CRUD api controllers
as I think through it. idk.

So when it comes down to it E-Tag's only really seem useful for:

I'm trying to think of ways to reduce the amount of computation needed to
generate the e-tags.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[andheiberg]

haha yeah, glad I'm not insane here.

Well what is kinda bothersome is that when I researched this maybe like 2 years ago I don't remember finding any resources talking about making such a scheme.

I mean you have to be at an incredible scale for it to be worth the effort for merely saving bandwith.

I'm in it for the speed and simplicity of my client, but if you're not doing a caching scheme where you're just checking the md5 hash, then you're really not getting that much of a speed improvement.

I wonder what the complexity would be of such a system. I feel like someone must have written about their implementation.

[fideloper]

Would definitely be interesting to find someone using it! I think the most
useful one would be based on the lost update problem, but that's only worth
it if you have a problem of peope's changes over-writing each other (google
docs might make use of this? Or maybe they do something fancier. Perhaps
any write-heavy API, but I'll bet a lot of them skip this in favor of just
letting the last update win for simplicity).

On Wed, Sep 23, 2015 at 9:27 AM Andreas Heiberg [email protected]
wrote:

haha yeah, glad I'm not insane here.

Well what is kinda bothersome is that when I researched this maybe like 2
years ago I don't remember finding any resources talking about making such
a scheme.

I mean you have to be at an incredible scale for it to be worth the effort
for merely saving bandwith.

I'm in it for the speed and simplicity of my client, but if you're not
doing a caching scheme where you're just checking the md5 hash, then you're
really not getting that much of a speed improvement.

I wonder what the complexity would be of such a system. I feel like
someone must have written about their implementation.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.