Defer

Going to miss seeing this in the terminal @defer_run 😢

@programmerByDay cc @triggerdotdev

unfortunately @defer_run is shutting down in a month. Do you guys know any similar services? Or how I can run my tasks on my own server?

The first Defer Build Week is over 🚀 See how Defer can help overcome Serverless limitations, build LLM applications faster, and achieve complex no-code UI in no time: defer.run/blog/build-wee…

Are you building a no-code workflow builder UI? You might want to save some time by using Defer's API and Platform to power it with a few lines of code ✨ Checkout our live open-source demo of a User Notification Builder UI, deployable on @vercel: defer.run/blog/build-wee…

Do you want to use @nextjs for your LLM application but cannot stream the response for your use case? We got you covered with `@defer/client/next` to integrate long-running executions in your Client Components ⚡️ Ready-to-deploy demo available here: defer.run/blog/build-wee…

When working with Serverless, how do you cope with your Email Provider rate limit or IP Reputation upon traffic spikes, and how do you build more advanced email-based features relying on schedules? Here's a monthly usage billing email demo with @resend: defer.run/blog/build-wee…

🔥👀

Building AI products requires processing large datasets, videos, and audio, which has many challenges (ex: timeouts) Day 2 of Defer Build Week covers a practical use case of LLM workflow, processing large meeting video files with @OpenAI Whisper at scale: defer.run/blog/build-wee…

This week is Defer Build Week 🚀 Every day, a ready-to-deploy demo of Defer covers an essential use case. Let's start by processing webhooks with @stripe 🪝 defer.run/blog/build-wee…

I often hear or get replied: "I'll just deploy a Redis, that's simple" Here is a good summary of the challenges of building your own workers/jobs processing solution:

We are happy to release `@defer/client@2.0.0`, bringing most of our scheduling feature to the local development 🚀 Find the complete list of locally supported features in our announcement post: defer.run/blog/local-fir….

We are opening our Scheduler to @nodejs and @nextjs developers with a new major version of our API, enabling listing tasks with your apps and advanced scheduling capabilities. Learn more in our announcement: defer.run/blog/advanced-… #Node #CRON #scheduling

🚀

🎉 Unleash the Serverless elephants! 🐘 Small, Medium, and Large @PostgreSQL databases with up to 4GB of RAM are available in 🇺🇸🇩🇪🇸🇬 🆓 Forever free tier provides 50 active hours/mo 💰 Save up to 88% compared to traditional databases Read more or 🧵 koyeb.com/blog/koyeb-ser…

We're excited about @defer_run, the best platform to develop and deploy part of your application that rely on scheduling such as sending email campaigns or running LLM workflows. defer.run

@manoj_ahi @render @Railway I strongly recommend @defer_run over @Railway and @render if all you need is long running bg tasks!

Defer applications can now be synced with @vercel ones, thanks to our new Vercel Integration ✨ Add @nextjs Server Actions support and get the best experience to defer in the background code that requires time or native deps. Discover more at defer.run/blog/defer-ver….

@inakitajes @calisteniapp ¡Estamos orgullosos de ser parte de tu viaje en la construcción de tu producto! 🚀

Esto empezó como un tweet de dos líneas. Para variar, me he liado y se ha convertido en un post #buildinpublic . Al lío! Ando estos días diseñando e implementando algunos flujos básicos de user journeys para aumentar las conversiones de @calisteniapp . Llevo meses aplazándolo, pero es que no nos da la vida!! La teoría nos dice que es algo esencial en cualquier negocio digital. Veremos que tan bien lo llevo a la práctica. Inicialmente, valoré integrar algún SaaS específico para estas cuestiones como OneSignal, Segment o Braze. Pero me echaban para atrás algunas cosas: - Son caras que da miedo, con mínimos bastante elevados. - Son un poco overkill para la capacidad que tengo (me suele pasar con muchas herramientas profesionales). Es decir, si no tienes a alguien dedicado al 100% a ellas, olvídate de sacarles partido. - No podemos hacer un test rápido. Conllevan tiempo de integración, configuración de sdks cliente, cambios en las políticas de privacidad y un largo etc. - Una herramienta más = más ruido. Por todo esto, e intentando seguir el lema "Menos es más", me voy por la segunda opción: reinventar la rueda. Sí, suena fatal y es algo de lo que siempre intento huir. Si hay un software específico, ¿por qué no usarlo? Y es que una implementación propia es algo arriesgado y también lleva tiempo. No obstante, con los años he aprendido (o eso creo), que en algunos casos puede ser una opción a valorar. En resumidas cuentas: - Reinventar la rueda de algo barato -> malo. - Reinventar la rueda de algo complejo -> malo, malo. - Reinventar la rueda de algo sencillo y rápido -> se puede valorar. Valoremos pues. En nuestro caso, queremos crear un solo user journey y monitorizar el impacto para dar unos primeros pasos (de menos, a más). Para ello necesitaremos: 1. Definir el flujo y automatizarlo -> no lo tenemos. 2. Definir las audiencias y crear disparadores -> sí, triggers de firebase cloud functions + mixpanel. 3. Comunicación -> Sí. Firebase messaging (push) + in-app inbox (solución propia ya implementada). 4. Análisis -> Sí, Mixpanel. Las soluciones que mencioné, como OneSignal, son más o menos all-in-one. Pero en nuestro caso, ya tenemos casi todo solucionado con nuestro propio stack de herramientas. Los únicos puntos que nos quedarían sería el primero y una mejora del tercero para añadir email transaccional. Para la gestión de los flujos he estado valorando @inngest y @defer_run . Aunque no termino de quedarme con un ganador, apostaré por el segundo. Ambos son muy atractivos, cada unos con sus pros y sus contras. Para los emails probaremos @resendlabs , que tiene super buena pinta y me han hablado muy bien de la DX (developer experience). Combinaremos todo con @mixpanel para identificar audiencias objetivo y analizar los resultados de los embudos. De esta manera, podremos probar un flujo básico del tipo: 1. Usuario se registra. 2. Se dispara el envío del email de bienvenida. 3. Se esperan acciones con un timeout de X días. 4. Se le envía una recomendación in-app basada al X acciones. 5. Se espera X días. 6. Se comprueban algunas condiciones y se le envía una oferta. 7. Etc (esto es solo un ejemplo). La mayor complejidad estaría en la gestión de la arquitectura orientada a eventos, pero el heavy lifting lo hará inngest a un precio permisible y pay-as-you-go, con lo cual bastante predecible y controlable. Deséenme suerte! Estos días pasaré a la implementación del primer flujo y lo estaremos probando unas semanas. ¿Y tú? ¿Has probado alguna de las soluciones que he mencionado? ¿Algún consejo? Leo opiniones y comentarios :)

Thanks, @Defer! We're thrilled to be your search and AI partner for docs 😎🚀 Simple and elegant #DocSearch implementation too ✨👏 Favorite page? They're all top-notch, so choosing a favorite is tough! 👀

@programmerByDay Hi @programmerByDay! Environment variables are encrypted at rest and also encrypted with a PGP symmetric key, making it impossible to access them outside of a runner environment running inside our zero trust infrastructure. The same goes for all sensitive data like tokens, etc.

@defer_run is a promising project. I just wish its env variable management was a bit more secure. I feel like i’m exposing my env vars, not sure how secure it is behind the scenes.