Començo donant les gràcies a les coses bones de l’any passat i les que no han sigut tan bones però que m’han fet veure el món des d'un altre punt de vista. I pels que voleu fer del món un de millor i de més segur, doncs et desitjo també el mateix, que compleixis els teus objectius i que res t’aturi. Bon any nou 2026.
Vull finalitzar aquesta serie d’entrades al meu bloc sobre el projecte que vaig començar i que vas veure des del primer dia com es desenvolupa. Com ja saps, disposes de tota la resta aquí(Per ordre):
-Projecte Flask + S3: De 0 a connectat/ Preparació de l’entorn i requisits previs.
-Projecte Flask + S3 #2: El cervell i la xarxa de seguretat/ Importància de la classe S3 i de les proves de funcionament.(Pytest)
-Projecte Flask + S3 #3: Del servidor local a S3/ Blueprints, connexió amb AWS S3, seguretat de pujada al bucket, html de Flask i templates.
Arquitectura
Quan miro el projecte ja acabat veig 3 capes que conformen un engranatge: la capa Client, la Service i la Flask.
M’ha agradat posar-me amb aquest repte per què m’he adonat que he pogut passar de intentar entendre com funcionava Python a veure que sóc capaç de construir, això és molt més avançat que el que feia mesos abans.
- Capa Client: La que parla llenguatge d’Amazon(boto3), en el cas que un dia Amazon deixes de parlar de la mateixa manera, hauriem de venir a aquesta capa. De fet, ho tinc tot pensat per treballar d’aquesta manera perquè és actualment on estic certificat, però també hi ha altres serveis similars com Azure de Microsoft o Google Cloud. En el cas que tinguem una aplicació i la volguessim migrar aquesta seria la part a canviar.
- Capa Service: Decideix la lògica, on especifiquem la mida dels arxius que poden entrar, que siguin noms segurs… No parla amb Amazon directament sinó que pren decisions.
- Capa Flask: La que rep l’usuari, rep fitxers i mostra missatges senzills. Aquesta només es comunica amb l’usuari.
Una de les tantes bones decisions que he anat aprenent i prenent és que he aconseguit dividir correctament el projecte, si no ho hagués fet d’aquesta manera, seria com intentar moure un mur de formigó, però connectant-lo amb ara que ha vingut el Nadal i m’han caigut unes figures de LEGO havent construit aquestes capes ha sigut com si construissim una figura d’aquestes, on les peces encaixen correctament.
Eficiència
Aquesta modularitat no és només estètica, ens permet ser eficients. Aquí és on podem parlar d’una altra decisió important: he fet que els arxius es pugin directament, l’arxiu passa per la RAM però no es queda ocupant al disc al servidor. És el que vam parlar de l’upload_fileobj.
Seguretat no visible
He pensat també amb molta cura de la seguretat, quan “construeixo” és una de les característiques que m’agrada aturar-m’hi més. Pensar en què podria sortir malament, com he comentat abans: Establir noms nets, IDs que siguin únics i que no creïn conflictes emprant UUID, que siguin d’un tipus d’extensió: jpg, png, txt… i determinant la grandària en aquest cas un màxim de 3 MB per arxiu. Totes aquestes mesures tot i ser invisibles són importants.
Ara tinc un control total des de l’aplicació: puc llistar, esborrar, descarregar i crear nous buckets(contenidors), amb un únic clic.
Si t’ha agradat l’explicació sobre el gestor o vols provar a fer el teu propi, et convido a fer un cop d’ull al codi del meu repositori. Qualsevol feedback és benvingut!
Comentaris
Publica un comentari a l'entrada