Sebastián Ramírez (tiangolo) is presenting the keynote "Behind the scenes of FastAPI and friends for developers and builders" closing the second day of EuroPython 2025 in Prague.
Sebastián Ramírez (tiangolo) is presenting the keynote "Behind the scenes of FastAPI and friends for developers and builders" closing the second day of EuroPython 2025 in Prague.
Rack Root update: tonight I finally got the search page working and passing parameters the way I need it to. There's a search box in the top right hand corner that will take in a given string and (eventually) go ask the API for objects that match the search terms.
This took a while to put together since entering a search term will redirect you to `/search?q=foo` and that renders properly the first time. With Vuetify however, if you enter another search term while on that page, the app sees you're already on `/search` and doesn't update the values on the page, even though the search parameter is different.
The solution was thankfully found in a GitHub issue (linked below) where other people were looking for the same kind of functionality. This also taught me about the Navigation Guards that Vue/Vuetify come with to handle page navigation/movements. The app knows when you're on the same page and will make decisions based on that.
During my testing I just echoed the search parameter back to the user, but now that the hard part is done, I just need to write the API for it and render that on the frontend. Surely there won't be any complications with asking the API for multiple different objects back... that'll really test my database and python skills.
https://github.com/vuejs/router/issues/1257#issuecomment-2072052011
I wrote a few words on my new work environment — I’m not an iOS dev amymore, but write #Python code with #fastapi nowadays. And I also decided to postpone the purchase of a new computer for another month or so. It will most likely be a @frameworkcomputer
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.
Take me back to ASP.NET please.
I'm presenting at the Wellington Python New Zealand meetup on Thursday evening, so if you're in town come along and cheer.
The subject is integrating #OAuth into a #Django project : what OAuth is and how it works; a good approach to integrating it into a Django project ; and what benefits it brings.
Although the talk with be Django-centric I hope those attending will be able to contribute their experience of using OAuth in #Flask, #FastAPI etc.
Sign up is here : https://www.meetup.com/pythonnz-wellington/events/304242570/
I think the main reason that API frameworks commonly don't have built-in authentication and authorization controls is that there are too many different ways to do that, for many different use cases, each with their own benefits and drawbacks.
A highly-opinionated framework could include support for one type and declare it to be The Supported Auth Method. If none do that, perhaps there's a reason... but of course, you could always create such an opinionated package, if you thought it important enough.
There are almost always add-on packages available for a given framework implementing different approaches to this, giving you almost-zero-code integration with the auth type of your choice. Have you looked around for these sorts of add-on solutions?
Hope this isn't a strange question but why do API frameworks exist that do not support some type of user-management built-in?
What is the use-case of an API that has no authentication mechanism (user, API token, etc)?
And as a follow-up, which Python framework can I use to build an API that has user-management and admin dashboard baked in?
I've built an API/PWA using FastAPI that supports login, but I think that having my own user-management will be hackable.
I'm certain now. Writing #GraphQL server with #GoLang #gqlgen is considerably better than other libs in languages I tried. That includes #elixir, #Python, and even #typescript.
The library focuses so much on #schema first, you can off load the boilerplate to the generated code. Focus on the business logic of your api, not instrumenting.
Funny enough, if I was going with #REST, I would say #fastapi in python is the equivalent in productivity.
This afternoon's update focused on two things: testing and adding the foreign key relationship to the back end.
I re-enabled most of my tests which should make future development a lot faster, updated them a lot to cover the new foreign key for device types on inventory items, and added several tests for device types.
I'll integrate this with the front end now that the back end _should_ be good and see how that goes.
Latest code is up on my GitHub here https://github.com/alongchamps/rack-root
I finally have a functional foundation on which to build the front end for Rack Root. For some reason when I was working on it the past few days, the front end code was not cooperating. I reinitialized the project, copied in my existing (previously functional files) and the frontend would just complain about invalid javascript.
According to Visual Studio Code, everything looked good. I copied the relevant javascript out and it still looked good, no syntax errors. According to my console, there was a javascript error at the end of the </script> tag in the .vue file.
Whatever it was, I re-typed the relevant bits/pieces of my code, checked everything incrementally along the way, and got it back to working again.
Now I can start to write more of the back end code, get it all tested, write the front end to go with it, and so on. Repeat until 'done' ;)
Over the past few days, I've worked on a design document and started to generate some code for the front end for Rack Root. Now that I have some basis for the tables, I can start putting in the pydantic code to establish the object types, which also means I can start writing the CRUD operations on the back end.
Once that's in place, I plan to go after the basic skeleton of the frontend code such as setting up the navigation bar, settings page, and basic inventory operations.
https://github.com/alongchamps/rack-root/blob/main/design.md
I'm learning a lot more about how Vue works and I am liking it a lot. I now have full CRUD operations on:
Get all items
Get single item details
Edit item (via HTTP PUT)*
Create new item and redirect to the new item's detail page
Delete item from the 'all items' page
Delete item from the single item details page
* I also wrote a new backend API for the HTTP PUT operation and associated tests. I already had HTTP PATCH /items/{id}, but that didn't work with my existing code for the front end. I think Vue has a good way to do this with watchers, but I don't have enough understanding of that yet to use it. Maybe that's next!
As I've been going through this, I really got a good understanding of how to write APIs, how to name fields, leverage JSON, and other fun things. I like how it's coming together in Vue and plan to keep going with it.
I'm not doing anything yet with error handling so I know I need to start incorporating that. I also want to take a look at the watcher mechanisms.
Success - this is the line that took me entirely too long to write today:
itemsAffected = db.query(Item).filter(Item.id == item_id).update(dict(**foo.model_dump(exclude_unset=True)))
with a database session
query the Item table
for rows that match my item_id
update them with properties present in object foo (which is of type ItemUpdate) as a dictionary
There might be a better way for me to do this, but I didn't find an example online that lined up closely with what I was trying to do.
I did not want to have repeating code where it was repeating this for every property or even a foreach loop doing something similar, that feels inefficient:
if db_item.<field> != input_item.<field>
db_item.<field> = input_item.<field>
The Pydantic ItemUpdate has two properties: name and description. The model for the ItemUpdate class defaults to None for everything not specified so you can pass in just { "name": "newnamehere" } and the description property will remain untouched.
Now I just need to write tests against this to make sure it's all passing properly!
In my adventure to find a front end framework I like, I think I like Vue. I've seen a lot of FastAPI users use Vue, and even someone who said that's all they use with their FastAPI apps.
I have a basic list operation going here just pulling the JSON from the backend is working.
To test this some more, I'm going to make a page for individual items (so HTTP GET http://<server>/items/2) and see how I can render that.
Now I'm at the point where I'm working on a front end to my demo app and I have the basics of it working.
That being said, I think my testing might need to change a little bit since my response_model in FastAPI will be changing from a Pydantic type (Item) to HTMLResponse.
I think I'll be able to adapt those as needed with the parsing abilities in pytest, but we'll see how it works out.
Tests are almost done, but that's definitely enough for tonight. I know pytest has a way, for example, to use an in-memory database so it's always empty and ephemeral, which would be perfect. But I'll figure that out in the morning.