TGCore Architecture Update!
Added new platform methods:
•
•
•
Example usage:
• Platform Tools
Added new platform methods:
•
tg.platform.tiktok.download()•
tg.platform.facebook.download()•
tg.platform.pinterest.download()Example usage:
resp = await tg.raw.chatCompletions()\
.model("kimi-dev")\
.messages(
[{"role": "user", "content": "say test"}]
)\
.stream(False).send(allow_object=True)
return resp.data.choices[0].message.content
• Platform Tools
await tg.platform.tiktok.download(url=url).send()
Why TGCore? Fluent Builder API Advantage
TGCore is an enterprise-grade Telegram SDK framework designed for scalable and secure Telegram automation.
Key capabilities include:
The Fluent Builder API has clean, chainable syntax for easy-to-read bot workflows.
Platform Tools: provides centralized services for multi-bot management.
AI integration: built-in support for modern AI providers
Lead Architect: @zxyeor
Unlike traditional Telegram SDKs that rely on nested calls and verbose syntax, TGCore introduces a fluent builder architecture that simplifies complex operations.
This design reduces repetitive code, avoids patterns that use too many callbacks, and allows developers to build large-scale Telegram automation systems with code that is easy to use.
TGCore is an enterprise-grade Telegram SDK framework designed for scalable and secure Telegram automation.
Key capabilities include:
The Fluent Builder API has clean, chainable syntax for easy-to-read bot workflows.
Platform Tools: provides centralized services for multi-bot management.
AI integration: built-in support for modern AI providers
Lead Architect: @zxyeor
Unlike traditional Telegram SDKs that rely on nested calls and verbose syntax, TGCore introduces a fluent builder architecture that simplifies complex operations.
This design reduces repetitive code, avoids patterns that use too many callbacks, and allows developers to build large-scale Telegram automation systems with code that is easy to use.
You can do it in a single line no need for verbose code.
PyPi: https://pypi.org/project/tgcore/1.0.52/
resp = await tg.raw.chatCompletions().model("kimi-dev").messages(
[{"role": "user", "content": "say test"}]
).stream(False).send(via_chat=True)
return resp.text()PyPi: https://pypi.org/project/tgcore/1.0.52/
Developers writing long kwargs everywhere:
"
TGCore devs:
"
"
send_message(chat_id=..., text=..., ...)"TGCore devs:
"
tg.raw.sendMessage().chat_id(id).text("hi").send()" 😈ev user = await tg.platform.facebook.download(url="https://www.facebook.com/share/r/1FNECz3fP7/").send(via_result=True)
await tg.raw.sendVideo().chat_id(m.chat.id).video(user.video_url(0)).skip()
await tg.raw.sendVideo().chat_id(m.chat.id).video(user.video_url(0)).skip()
ev user = await tg.platform.blackforest.image().query("Make a picture of a cat clothes logo architecture, background color Abstraction").send(via_result=True)
await tg.raw.sendPhotoUpload().chat_id(m.chat.id).photo(tg.writer(user.image_bytes(), True)).skip()
await tg.raw.sendPhotoUpload().chat_id(m.chat.id).photo(tg.writer(user.image_bytes(), True)).skip()
Why Do Architects Choose Fluent Builder?
This is Rendy Projects, a channel built around architecture.
In the past, whiteboards were filled with static functions.
As parameters grew, the code became harder to read, harder to scale, and easy to break.
With a Fluent Builder approach, things change.
Instead of writing long parameter lists, you compose the request step-by-step:
If the old method was like riding a public bus fixed routes, limited control then the Fluent Builder is like driving your own car.
You decide where to stop.
You decide the order.
You decide the flow.
Stop at
That freedom is why architects prefer builder patterns.
This is Rendy Projects, a channel built around architecture.
In the past, whiteboards were filled with static functions.
As parameters grew, the code became harder to read, harder to scale, and easy to break.
With a Fluent Builder approach, things change.
Instead of writing long parameter lists, you compose the request step-by-step:
tg.raw.send()
.chat_id()
.photo()
.skip()
If the old method was like riding a public bus fixed routes, limited control then the Fluent Builder is like driving your own car.
You decide where to stop.
You decide the order.
You decide the flow.
Stop at
.skip() or go straight to .send().That freedom is why architects prefer builder patterns.
TGCore SDK architecture bersih, bukan parameter hell.
Open source: https://github.com/TeamKillerX/tgcore/
Open source: https://github.com/TeamKillerX/tgcore/
Fluent Builder vs Parameter Hell
❌ Old Method Parameter Hell
✅ Fluent Builder TGCore Style:
Retrieving the output file
Your code could also be tidied up a bit:
The core architecture that you show
Parameter API:
Fluent Builder:
❌ Old Method Parameter Hell
from something.types import OthersHell
await instagram_download(
type="instagram",
url="https://www.instagram.com/reel/...",
options=OthersHell.HELL,
timeout=30,
quality="best"
)
Problem:
More and more parameters
Hard to read
Difficult to extend
Breaking change when the API changes
✅ Fluent Builder TGCore Style:
user = await tg.platform.tools\
.types()\
.platform("instagram")\
.url("https://www.instagram.com/reel/...")\
.send(via_result=True)
More clearly:
Every step is explicit
The API can be extended without breaking the signature.
More readable
Retrieving the output file
Your code could also be tidied up a bit:
resp = await tg._ensure_client().get(user.ig_url()[0])
video = tg.writer(
"mp4",
image_bytes=resp.content
)
return video
The core architecture that you show
Parameter API:
function(parameter1, parameter2, parameter3...)Fluent Builder:
object.step().step().step().execute()Design pattern:
• Fluent Interface
• Builder Pattern
• Composable API
Stop fighting parameter hell. Start designing APIs.