Un altre descobriment en aquest camí ha estat #Pydantic. Com podia viure programàticament parlant sense Pydantic?
Pydantic és una biblioteca de Python que serveix per validar i gestionar dades amb tipus. Et permet definir models (com classes) on s’especifica el tipus de cada camp, i automàticament valida i converteix les dades rebudes. Integrat a la perfecció amb fastAPI.
Totes les aplicacions client per Android funcionen amb #appy i el mateix passa amb les de iOS. Aquesta és la clau, volia aprofitar totes les apps existents per tant l'API havia de ser una copia de la de Mastodon però feta amb fastAPI, que ha resultat una tria excel·lent. fastAPI és brutal, fa tot i més i molt bé. I, a més, et genera automàticament la documentació sense ni preocupar-te per ella. Insisteixo, brutal.
L'estructura tècnica d'#appy funciona gràcies a Python, fastAPI, #Postgresql (base de dades) i #Redis (memòria cau).
Tot de manera asincrona per evitar punts de bloqueig, passen moltes coses en parall·lel, simultàniament, bàsic per a tenir fluïdesa tant en les interaccions amb altres servidors com amb les aplicacions client.
appy funciona bé fins i tot en una #Raspberry 4B, per tant també és una opció vàlida per a tenir el perfil fediversal auto gestionat i a casa.
Quan vaig posar en marxa mastodont.cat no en sabia res de Python i ActivityPub no existia (Mastodon funcionava a les hores amb el protocol Ostatus de GNU Social).
Qui podria pensar que acabaria programant el meu propi servidor? sí, estic content d'haver-ho aconseguit i de compartir el resultat amb la comunitat de programari lliure a https://codeberg.org/spla/appy
Queda feina encara però sí, ja ho considero un èxit 
Queden algorismes per polir, afegir funcionalitats com ara bloquejar o silenciar usuaris i servidors i depurar incidències però ja considero que #appy és un èxit.
Des de juny de l'any passat he estat (i estic) molt centrat en desenvolupar el meu propi servidor ActivityPub des de zero, sense copiar res de ningú, per pur plaer personal de superar reptes. He après molt pel camí, no és gens fàcil però he gaudit molt de cada fita.
Va ser tot un encert triar #Python i #fastAPI, van sobrats.
He alliberat la primera versió, la v0.1, de #appy, el servidor #ActivityPub escrit en #Python sobre #fastAPI
https://codeberg.org/spla/appy/releases
La majoria d'aplicacions per a Mastodon funcionen amb appy.
Ara millor, la línia de temps "home" necessita un token vàlid però la línia de temps "public" (federada) no.
https://codeberg.org/spla/appy/commit/081cf661cc33d702cd0e53a74ab9030fbffd9311
He tingut que crear un nou model #Pydantic per els tuts de la línia de temps federada perquè no han de tenir "favourited", "reblogged", "muted", "bookmarked", "pinned" ni "filtered"
He modificat #appy evitant repetir les mateixes línies de codi que verifiquen el token d'accés de l'aplicació client en els punts finals de l'API on es requereix un token d'accés.
El resultat final estalvia 537 línies.
"Dependency Injection" a #fastAPI és un sistema molt fàcil i a l'hora molt potent d'evitar repetir el mateix codi en tots els punts finals (endpoints) de l'API.
En cadascun dels punts finals fas una crida a la funció que vulguis mitjançant el paràmetre "Depends", funció que verifica que es compleix el requisit necessari, en l'exemple, l'aplicació client ha d'enviar el token correcte, si no és així, la funció que executa Depends és l'encarregada de retornar l'error a l'app client.
![codi d'un punt final a fastAPI on es mostra una Dependency Injection:
’@app.get('/api/vl/blocks', status_code=200) async def get_blocks( tokens: Annotated[dict, Depends(get_tokens)], max_id: str = None, since_id: str = None, min_id: str = None, limit = Query(default=40) ) 8 user_id = await db.get_token_resource_owner_id(tokens['app']) auth_account_id, auth_username, auth_domain = await db.get_account_id_from_users(user_id) accounts = await db.get_blocks(auth_account_id, limit, max_id, since_id, min_id) content = await build_blocks(accounts) return content](https://mastodont.cat/system/media_attachments/files/114/149/364/326/650/680/original/cc1fe34e7be4b893.png "codi d'un punt final a fastAPI on es mostra una Dependency Injection:
’@app.get('/api/vl/blocks', status_code=200) async def get_blocks( tokens: Annotated[dict, Depends(get_tokens)], max_id: str = None, since_id: str = None, min_id: str = None, limit = Query(default=40) ) 8 user_id = await db.get_token_resource_owner_id(tokens['app']) auth_account_id, auth_username, auth_domain = await db.get_account_id_from_users(user_id) accounts = await db.get_blocks(auth_account_id, limit, max_id, since_id, min_id) content = await build_blocks(accounts) return content")
https://kitfucoda.medium.com/writing-a-telegram-bot-in-python-866972ab63f5
I've just finished writing up a deep dive into building a Telegram bot with a FastAPI web application, and it was quite the journey into asynchronous Python! 
The project started with a desire to run chatbots across multiple platforms, but quickly evolved into a focused exploration of asyncio. I found myself wrestling with event loops, queues, and the nuances of asyncio.create_task vs. asyncio.to_thread. It became very clear that understanding the difference between concurrency and parallelism is absolutely crucial in this space. Clever scheduling can mitigate blocking, but over-scheduling will inevitably lead to performance issues.
Architectural considerations became a major focus. I learned firsthand that cramming everything into a single process, while tempting, isn't always the best approach. Separating processes for scalability and future enhancements is something I'll definitely keep in mind for future projects.
This project was a great learning experience, and I'm looking forward to applying these lessons to future projects. If you're interested in asyncio, webhooks, or building chatbots, I'd love to hear your thoughts!
#python #asyncio #telegrambot #fastapi #webdevelopment #programming #opentowork #fedihire
Take me back to ASP.NET please.
Fun #Python #FastAPI problem today.
I was writing my own error catching middleware to force errors into a specific format.
It seems that returning a 204 - no content status from my API raises a HTTPException. This got caught in the error catcher and caused problems when suddenly some JSON content was generated.
Locating this problem was quite challenging.
After adding special "no content" handling, that problem went away.
If you write your own error handler, consider this case!
Finally had time to add examples to the htmy docs on how to use plain #html snippets and dynamically replace their slots with components. It's easier than understanding the previous sentence
Works with #htmx by design. You can check out the example here: https://volfpeter.github.io/htmy/examples/snippet-slots-fastapi/
Ara sí que tinc dominat, a #appy, els possibles errors al seguir un usuari remot.
Mireu el missatge d'error en vermell que li envio a l'aplicació client Ivory quan això passa.
Brutal.
Afegint control d'errors en la creació de la base de dades de #appy. Quan instal·les el servidor appy, si hi ha un error en la creació d'una taula, un index, una seqüència o una funció, el codi et mostra on és l'error i surt al sistema.
Pro #Python mám slabost co se týče web scrapingu a zpracování dat či jednorázových skriptů, nicméně co se týče webového vývoje, tak mám raději PHP, resp. Laravel. Až na jednu výjimku. Pro (REST) API mám nejraději Python framework #FastAPI 
viz https://fastapi.tiangolo.com
Which Is the Best Python Web Framework: Django, Flask, or FastAPI?
#Pycharm #Webdevelopment #Django #Fastapi #Flask #Python
https://blog.jetbrains.com/pycharm/2025/02/django-flask-fastapi/
FastAPI is now one of the most popular web frameworks on GitHub!
In an exciting milestone, FastAPI has officially surpassed Laravel (PHP) and Gin (Go) in GitHub stars! 
This achievement highlights the growing popularity of modern, high-performance Python web frameworks.
FastAPIとSQLAlchemyを使って、10分でREST APIを作ってみた
https://qiita.com/Kumacchiino/items/8c3793a272f276cd4072?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items
Qiita - 人気の記事