Our great sponsors
-
I'm in the process of migrating PrintNanny.ai's remote command/event system off Cloud IoT Core. I've been running on IoT Core for 1.5 years. Here's my breakdown of the costs...
- $236.99 in usage, approx 1% of project's total revenue
- ~20 hours to implement pub/sub applications running on a mix of Raspberry Pi & GCP VMs. Implementations were in Rust and Python. It would have taken much, much longer to stand up a managed MQTT broker and identity/key management that I felt comfortable using in my own home, let alone providing to customers.
- Hundreds of hours implementing and debugging glue between GCP's Pub/Sub product, websocket-based subscribers, and MQTT subscribers/publishers.
I don't regret my decision (wouldn't have shipped otherwise), but I'm looking forward to the next phase. Here's what I'm migrating towards:
- NATs message broker. NATS supports connections via MQTT and Websocket protocols, besides NATS own protocol.
- django-nats-nkeys for org, identity, and JWT management (not production-ready, don't use this until I've been eating my own dog food for a few months) [1]
- AsyncAPI schemas [2] for core message APIs, including schemas for 3rd-party printer software events (OctoPrint, Moonraker, Repetier, etc). This will underpin PrintNanny's plugin system.
-
spec
The AsyncAPI specification allows you to create machine-readable definitions of your asynchronous APIs. (by asyncapi)
I'm in the process of migrating PrintNanny.ai's remote command/event system off Cloud IoT Core. I've been running on IoT Core for 1.5 years. Here's my breakdown of the costs...
- $236.99 in usage, approx 1% of project's total revenue
- ~20 hours to implement pub/sub applications running on a mix of Raspberry Pi & GCP VMs. Implementations were in Rust and Python. It would have taken much, much longer to stand up a managed MQTT broker and identity/key management that I felt comfortable using in my own home, let alone providing to customers.
- Hundreds of hours implementing and debugging glue between GCP's Pub/Sub product, websocket-based subscribers, and MQTT subscribers/publishers.
I don't regret my decision (wouldn't have shipped otherwise), but I'm looking forward to the next phase. Here's what I'm migrating towards:
- NATs message broker. NATS supports connections via MQTT and Websocket protocols, besides NATS own protocol.
- django-nats-nkeys for org, identity, and JWT management (not production-ready, don't use this until I've been eating my own dog food for a few months) [1]
- AsyncAPI schemas [2] for core message APIs, including schemas for 3rd-party printer software events (OctoPrint, Moonraker, Repetier, etc). This will underpin PrintNanny's plugin system.
-
Appwrite
Appwrite - The Open Source Firebase alternative introduces iOS support . Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!
-
'Stadia isn't going anywhere soon, or the people working in the division haven't been told and have continued spending money left and right with partnership deals, which would be a weird waste of money.'
LOL, that is Google 101.
Allow me to introduce you to the Google Graveyard[1]
Related posts
- There's a 90% chance TikTok will be banned in the US unless it goes through with an IPO or gets bought out by mega-cap tech, Wedbush says
- How much does not having propriety / non standard Markdown syntax in your notes, matter to you?
- I think Bard sometimes does represent Google's views
- LPT: For anyone who's forgetful.
- Google Groups has been left to die