litestar-org / litestar

Production-ready, Light, Flexible and Extensible ASGI API framework | Effortlessly Build Performant APIs
https://litestar.dev/
MIT License
5.51k stars 376 forks source link

Documentation: Add Recipes section to Docs #446

Closed Goldziher closed 1 year ago

Goldziher commented 2 years ago

This is a suggetion- we could add a cache reserved kwarg, which will cause starlite to inject the cache backend to route handlers:

from starlite import Cache, get 

get("/")
async def handler(cache: Cache) -> dict | None:
   return await cache.get(...)

This is merely an ergonomics improvement, because users can access the cache already by going the somewhat longer route of doing this:

from starlite import Request

get("/")
async def handler(request: Request) -> dict | None:
   return await request.app.cache.get(...)

Fund with Polar

peterschutt commented 2 years ago

Given that it is pretty easy for a user to write a small convenience dependency to do the same, e.g.,:

@get("/")
def using_the_cache(cache: Cache) -> ...:
    ...

def provide_cache(request: Request) -> Cache:
    return request.app.cache

app = Starlite([using_the_cache], dependencies={"cache": Provide(provide_cache)})

Add to that it would be breaking for anyone already using cache as a parameter name in a signature and I'm not sure it is worth the churn.

Maybe something we could consider is curating a collection of dependencies that users could use if they want - basically would save them the hassle of having to write the dependency function for common things like this. E.g., from starlite.dependencies.lib import provide_cache. It could be a good middle ground. Thoughts?

Goldziher commented 2 years ago

That's a very good idea!

What utils and dependencies do you have in mind?

peterschutt commented 2 years ago

Idea purely inspired by this issue, so I don't really have any thoughts beyond that, but I'm sure there would be a few different things that can be accessed through the request via a couple of hops like the cache..

What about a structured log instance that is pre-bound to some app/request context?

We could always start with recipes in the docs to see if there's enough interest to warrant the work of maintaining them.

Goldziher commented 2 years ago

Ok. But we still need to inventory what we want to add - even as recipes

peterschutt commented 2 years ago

Shall we make a new issue, or hijack this one?

Goldziher commented 2 years ago

Shall we make a new issue, or hijack this one?

Hijack

Goldziher commented 2 years ago

@peterschutt so what should we include?

abdulhaq-e commented 2 years ago

Hello, thanks for the awesome framework.

If you're looking for ideas for recipes, I'm right now looking at overriding dependencies when writing tests. I'm trying it now, I can contribute to that if you all decided it's a good recipe.

Goldziher commented 2 years ago

Hello, thanks for the awesome framework.

If you're looking for ideas for recipes, I'm right now looking at overriding dependencies when writing tests. I'm trying it now, I can contribute to that if you all decided it's a good recipe.

You're welcome 😉

Sure, we are keen on PRs