Backend y Fullstack

Backend & Fullstack Daily — 30 Jun 2026

Lo nuevo hoy

Today's highlights

Points forts du jour

Click en cualquiera para ir al detalle

Click any item to jump to the full section

Cliquez un élément pour aller à la section complète

🔥

Top Stories

Seguridad

npm congela en read-only por 72h las cuentas de alto impacto ante cambios sensibles

El 25 de junio npm sumó un freno preventivo para las cuentas de alto impacto — las que mantienen los paquetes más usados del registro. Cuando una de esas cuentas cambia el email o usa un código de recuperación de 2FA, npm la pone en estado read-only por 72 horas y manda una alerta al email anterior. Durante ese período podés instalar, descargar y mirar settings, pero publicar, mintear tokens, cambiar visibilidad de paquetes o tocar membresías de org queda pausado. Esto tapa exactamente el vector que explotaron los últimos ataques de supply chain: cuenta comprometida → cambian el email → mintean un token nuevo → publican versiones maliciosas. Tarde pero buenísimo: el registro deja de confiar ciegamente en una sesión autenticada.

25 Jun 2026
github.blog →
Destacado

GitHub Actions: pasos en paralelo nativos con background, wait y parallel

El 25 de junio GitHub Actions resolvió una limitación histórica: los steps ahora corren en paralelo de verdad. Antes, todo step esperaba a que terminara el anterior. Llegan keywords nuevas: background: true lanza un step async y sigue al siguiente; wait / wait-all pausan hasta que uno o todos los steps en background terminen; cancel corta limpio un step en background que ya no necesitás (ideal para levantar servicios efímeros); y parallel es azúcar sintáctico que agarra un grupo de steps, los corre concurrentes y mete un wait al final. Lo importante para la DX: a diferencia del viejo truco de mandar todo al background del shell, cada step mantiene sus logs separados sin interleaving. Si tenés jobs con builds o tests independientes dentro del mismo runner, esto te acorta el wall-time sin partir el workflow.

25 Jun 2026
github.blog →
Seguridad

GitHub Actions emite tokens de caché read-only para triggers no confiables

El 26 de junio GitHub cerró un agujero clásico de cache poisoning en CI. Ahora los eventos que se pueden disparar sin permisos de escritura — pensá pull_request_target y workflows desde forks — reciben tokens de caché read-only apuntados a la rama default. Antes, un trigger no confiable podía escribir una entrada de caché envenenada que después un workflow confiable (push, schedule) restauraba, abriendo la puerta a escalada de privilegios y robo de secrets. Los triggers de escritura habituales (push, schedule, workflow_dispatch, repository_dispatch) y los scopes fuera de la default branch conservan read-write. ¿Qué cambia para vos? Si tus workflows no confiables necesitaban cachear, ahora tenés que mover la escritura a un workflow confiable separado; actions/cache logea un warning al fallar la escritura pero el job sigue. Ojo si dependías de eso.

26 Jun 2026
github.blog →
☁️

Cloud & DevOps

Destacado

GitHub-hosted runners: grupos de macOS, labels desactivables y routing por política

También del 25 de junio: GitHub te da más control de gobernanza sobre los runners hosted sin tener que montar infra self-hosted. Ahora podés meter runners de macOS en runner groups y restringir el acceso por org, repo o workflow; desactivar los labels estándar (como ubuntu-latest) para forzar el uso de grupos configurados; y rutear jobs referenciando el grupo por nombre. Para equipos en Team/Enterprise esto significa imponer políticas de uso, manejar capacidad de macOS por límites de concurrencia y mantener compliance sin abrir la mano. Detalle: los runners de macOS todavía no soportan configuraciones de red.

25 Jun 2026
github.blog →
🏗️

Architecture & Best Practices

Minor

Cuándo los microservicios realmente tienen sentido (y cuándo el monolito modular gana)

Lectura del 24 de junio que conviene tener a mano para la próxima discusión de arquitectura. La tesis es sana y va contra el hype: los microservicios se justifican solo cuando se alinean condiciones organizativas y técnicas concretas — límites de dominio bien definidos e independientes, equipos estructurados para ownership autónomo, requerimientos de escalabilidad y disponibilidad que varían entre servicios, y necesidad real de diversidad tecnológica. Si eso no aplica, un monolito modular casi siempre es más simple y menos propenso a errores. El punto que más duele: los microservicios exigen madurez operativa real — Kubernetes, service mesh, observabilidad con OpenTelemetry — y sin esa base, lo único que ganás es latencia de red y debugging distribuido. Conceptos antes que arquitectura de moda.

24 Jun 2026
sachith.co.uk →
🔥

Top Stories

Security

npm freezes high-impact accounts read-only for 72h on sensitive changes

On Jun 25 npm added a preventive brake for high-impact accounts — the ones maintaining the registry's most widely used packages. When one of those accounts changes its email or uses a 2FA recovery code, npm drops it into a 72-hour read-only state and alerts the previous email address. During that window you can still install, download and browse settings, but publishing, minting tokens, changing package visibility or modifying org membership are paused. This closes the exact vector recent supply-chain attacks exploited: compromised account → change email → mint a fresh token → publish malicious versions. Overdue but excellent: the registry stops blindly trusting an authenticated session.

25 Jun 2026
github.blog →
Notable

GitHub Actions: native parallel steps with background, wait and parallel

On Jun 25 GitHub Actions fixed a long-standing limitation: steps now genuinely run in parallel. Previously every step waited for the prior one to finish. New keywords arrive: background: true launches a step async and moves on; wait / wait-all pause until one or all background steps complete; cancel gracefully terminates a background step you no longer need (great for ephemeral services); and parallel is syntactic sugar that takes a group of steps, runs them concurrently and appends a wait. The DX win: unlike the old shell-backgrounding trick, each step keeps its logs separate with no interleaving. If you have independent builds or tests inside one runner, this trims wall-time without splitting the workflow.

25 Jun 2026
github.blog →
Security

GitHub Actions issues read-only cache tokens for untrusted triggers

On Jun 26 GitHub closed a classic CI cache-poisoning hole. Now events that can be triggered without write permissions — think pull_request_target and fork workflows — get read-only cache tokens scoped to the default branch. Previously an untrusted trigger could write a poisoned cache entry that a trusted workflow (push, schedule) later restored, enabling privilege escalation and secret theft. Common write triggers (push, schedule, workflow_dispatch, repository_dispatch) and non-default-branch scopes keep read-write. What changes for you: if your untrusted workflows relied on caching, you must move writes to a separate trusted workflow; actions/cache logs a warning on failed writes but the job continues. Worth checking if you depended on it.

26 Jun 2026
github.blog →
☁️

Cloud & DevOps

Notable

GitHub-hosted runners: macOS groups, disable-able standard labels and policy routing

Also from Jun 25: GitHub gives you more governance control over hosted runners without standing up self-hosted infra. You can now add macOS runners to runner groups and restrict access by org, repo or workflow; disable the standard labels (like ubuntu-latest) to enforce configured groups; and route jobs by referencing the group by name. For Team/Enterprise teams that means enforcing usage policies, managing macOS capacity via concurrency limits and keeping compliance without loosening control. Caveat: macOS runners don't yet support network configurations.

25 Jun 2026
github.blog →
🏗️

Architecture & Best Practices

Minor

When microservices actually make sense (and when the modular monolith wins)

A Jun 24 read worth keeping handy for your next architecture debate. The thesis is healthy and cuts against the hype: microservices are justified only when specific organizational and technical conditions align — well-defined, independent domain boundaries, teams structured for autonomous ownership, scalability and availability needs that vary across services, and a genuine need for technology diversity. If that doesn't apply, a modular monolith is almost always simpler and less error-prone. The part that stings: microservices demand real operational maturity — Kubernetes, service mesh, OpenTelemetry observability — and without that base, all you buy is network latency and distributed debugging. Concepts before fashionable architecture.

24 Jun 2026
sachith.co.uk →
🔥

Top Stories

Sécurité

npm gèle en lecture seule 72h les comptes à fort impact lors de changements sensibles

Le 25 juin, npm a ajouté un frein préventif pour les comptes à fort impact — ceux qui maintiennent les paquets les plus utilisés du registre. Quand un tel compte change son email ou utilise un code de récupération 2FA, npm le place en lecture seule pendant 72 heures et alerte l'ancienne adresse email. Pendant cette fenêtre, on peut encore installer, télécharger et consulter les réglages, mais publier, générer des tokens, changer la visibilité d'un paquet ou modifier l'appartenance à une org sont en pause. Cela ferme précisément le vecteur exploité par les récentes attaques de supply chain.

25 Jun 2026
github.blog →
Notable

GitHub Actions : étapes parallèles natives avec background, wait et parallel

Le 25 juin, GitHub Actions a corrigé une limitation historique : les steps tournent désormais vraiment en parallèle. Avant, chaque step attendait la fin du précédent. Nouveaux mots-clés : background: true lance un step async et continue ; wait / wait-all mettent en pause jusqu'à la fin d'un ou de tous les steps en arrière-plan ; cancel termine proprement un step en arrière-plan devenu inutile ; et parallel est du sucre syntaxique qui exécute un groupe de steps en concurrence puis ajoute un wait. Le gain DX : contrairement à l'ancien backgrounding shell, chaque step garde ses logs séparés sans entrelacement.

25 Jun 2026
github.blog →
Sécurité

GitHub Actions émet des tokens de cache en lecture seule pour les triggers non fiables

Le 26 juin, GitHub a fermé un trou classique de cache poisoning en CI. Désormais, les événements déclenchables sans permissions d'écriture — par exemple pull_request_target et les workflows de forks — reçoivent des tokens de cache en lecture seule liés à la branche par défaut. Avant, un trigger non fiable pouvait écrire une entrée de cache empoisonnée qu'un workflow de confiance (push, schedule) restaurait ensuite, ouvrant la voie à l'escalade de privilèges et au vol de secrets. Les triggers d'écriture habituels gardent le read-write. À vérifier si vos workflows non fiables dépendaient du cache.

26 Jun 2026
github.blog →
☁️

Cloud & DevOps

Notable

Runners GitHub-hosted : groupes macOS, labels standard désactivables et routage par politique

Toujours du 25 juin : GitHub offre plus de contrôle de gouvernance sur les runners hosted sans monter d'infra self-hosted. On peut désormais ajouter des runners macOS aux runner groups et restreindre l'accès par org, repo ou workflow ; désactiver les labels standard (comme ubuntu-latest) pour imposer les groupes configurés ; et router les jobs en référençant le groupe par son nom. Pour les équipes Team/Enterprise : imposer des politiques d'usage et gérer la capacité macOS par limites de concurrence. À noter : les runners macOS ne supportent pas encore les configurations réseau.

25 Jun 2026
github.blog →
🏗️

Architecture & Best Practices

Mineur

Quand les microservices ont vraiment du sens (et quand le monolithe modulaire gagne)

Une lecture du 24 juin à garder sous la main pour votre prochain débat d'architecture. La thèse est saine et va contre le hype : les microservices ne se justifient que lorsque des conditions organisationnelles et techniques précises s'alignent — frontières de domaine bien définies et indépendantes, équipes structurées pour un ownership autonome, besoins de scalabilité et de disponibilité qui varient entre services, et un vrai besoin de diversité technologique. Sinon, un monolithe modulaire est presque toujours plus simple et moins sujet aux erreurs. Le point qui pique : les microservices exigent une vraie maturité opérationnelle — Kubernetes, service mesh, observabilité OpenTelemetry.

24 Jun 2026
sachith.co.uk →