You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I often use FastAPI to build the backend of my applications, so I was excited to see that I can write code using Python and FastAPI with Cloudflare Workers. However, after using it, I don't feel as comfortable as before.
For example, if I want to access my D1 database, I need to define the function's parameters as req: Request and use env = req.scope["env"] to get the env. Doing so means FastAPI can't help me validate my parameters, which is one of the main advantages of using it. Additionally, the lack of type hints makes development harder for me.
On top of that, the absence of an ORM for D1 makes it quite troublesome to use, do you have any plans to develop an ORM?
If we want to make SQLAlchemy work with D1 then we'd need to implement a Dialect for it.
If we add socket support then we can support hyperdrive in SQLAlchemy pretty much for free, and support hosted databases that way. But this won't work with D1.
Additionally, the lack of type hints makes development harder for me.
Yeah, I'd really love to see us offering type definitions like we do for TypeScript for our APIs. It's already on our todo list.
As this issue discussion environment variable, I also have some confusion.
Is that possible to get the env variable file wise, instead of getting this only in fetch function, like following code
model=ChatOpenAI(model="gpt-3.5-turbo", temperature=0,openai_api_key=env.OPENAI_API_KEY)
asyncdefon_fetch(request, env):
prompt=PromptTemplate.from_template("Complete the following sentence: I am a {profession} and ")
chain=prompt|modelres=awaitchain.ainvoke({"profession": "electrician"})
returnResponse.new(res.split(".")[0].strip())
As this is serverless function, does it still make sense to create variable/object outside of fetch function?
---Original---
From: "Peter ***@***.***>
Date: Tue, Apr 16, 2024 17:22 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [cloudflare/python-workers-examples] Suggestions for fastapisupport (Issue #3)
I may not express myself clearly, I want to get the env parameter outside of on_fetch is that possible?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
os.getenv requires all of the values to be strings, if we try to put anything else in there we get a type error. Since many of the bindings aren't strings, I don't think this is a good approach.
---Original---
From: "Hood ***@***.***>
Date: Tue, Apr 16, 2024 17:27 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [cloudflare/python-workers-examples] Suggestions for fastapisupport (Issue #3)
os.getenv requires all of the values to be strings, if we try to put anything else in there we get a type error. Since many of the bindings aren't strings, I don't think this is a good approach.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
As this issue discussion environment variable, I also have some confusion.
Is that possible to get the env variable file wise, instead of getting this only in fetch function, like following code
model=ChatOpenAI(model="gpt-3.5-turbo", temperature=0,openai_api_key=env.OPENAI_API_KEY)
asyncdefon_fetch(request, env):
prompt=PromptTemplate.from_template("Complete the following sentence: I am a {profession} and ")
chain=prompt|modelres=awaitchain.ainvoke({"profession": "electrician"})
returnResponse.new(res.split(".")[0].strip())
As this is serverless function, does it still make sense to create variable/object outside of fetch function?
how about the second question?
If I have an object which will be used across different request function? Shall I initialize this object outside of request or initialize this object in every request function? Since It is serverless function, I don't know what's the best practice here.
Activity
kflansburg commentedon Apr 4, 2024
We have plans for an SDK to make things more pythonic. I think that would be the best place to improve the FastAPI ergonomics for bindings.
Regarding ORM, I think it would make sense to try to support Sqlalchemy. Is that too opinionated?
hoodmane commentedon Apr 4, 2024
Pyodide already includes sqlalchemy. If we add raw socket support they should work very well together.
dom96 commentedon Apr 4, 2024
If we want to make SQLAlchemy work with D1 then we'd need to implement a Dialect for it.
If we add socket support then we can support hyperdrive in SQLAlchemy pretty much for free, and support hosted databases that way. But this won't work with D1.
Yeah, I'd really love to see us offering type definitions like we do for TypeScript for our APIs. It's already on our todo list.
kflansburg commentedon Apr 4, 2024
Agreed, wasn't sure what it was called, but Dialect is what I had in mind. Would be great to support both.
Qxxxx commentedon Apr 16, 2024
As this issue discussion environment variable, I also have some confusion.
hoodmane commentedon Apr 16, 2024
Well we do have a way to get the
envparameter likeQxxxx commentedon Apr 16, 2024
I may not express myself clearly, I want to get the env parameter outside of
on_fetchis that possible?StudyingLover commentedon Apr 16, 2024
hoodmane commentedon Apr 16, 2024
os.getenvrequires all of the values to be strings, if we try to put anything else in there we get a type error. Since many of the bindings aren't strings, I don't think this is a good approach.StudyingLover commentedon Apr 16, 2024
Qxxxx commentedon Apr 16, 2024
how about the second question?
If I have an object which will be used across different request function? Shall I initialize this object outside of request or initialize this object in every request function? Since It is serverless function, I don't know what's the best practice here.
hoodmane commentedon Apr 16, 2024
I think initializing at top level is fine for most purposes.