gautambt

Generated notebooklm here: https://notebooklm.google.com/notebook/7094a513-af83-4c5b-a4...

We've been using Argonaut for a while and have been a happy customer :) We deploy and manage our software on customers cloud accounts and Argonaut has been super useful for helping us manage all our deployments! Also a shoutout to Surya and his team for always being available in supporting us.

Bytebeam | REMOTE | https://bytebeam.io

Bytebeam is an IoT focused cloud platform. Bytebeam aspires to be a one stop destination for all the makers out there building new age smart & connected products.

Think of AWS but focused on IoT.

We are super passionate about solving the tough problems faced by the developers in this space. Some of the key use cases we solve for are:

* Collecting large volumes of data over unreliable networks

* Over the Air updates to improve device functionality over time

* Real time data visualisations and logs for insights and debugging

* Device and mobile SDK’s to sync data in real time between device and mobile

We have a highly skilled tech team with a collective experience of 40+ years working with startups & large enterprises like Flipkart, Samsung, Intel, Bosch, Juspay, Grinntech, Sandisk, Hasura, Ather Energy & more.

Bytebeam founders, in their last stint, built the connected & smart vehicle infrastructure at Ather Energy.

We are hiring for a bunch of roles: Senior Product Marketing, Embedded Engineers, Rust developers, Full stack developers to name a few. See our careers page for more: https://bytebeam.io/careers/

rumqtt is a set of MQTT client and broker libraries that we wrote in rust.

With this release, we add more visibility to rumqttd’s internals - focussing on its traceability and metering capability. Going forward we’ll build on top of these features to provide robust monitoring capabilities. We’ve also added native-tls support to rumqttc!

Read more about this release in our blog: https://bytebeam.io/blog/rumqtt-release-r18-traceability-met...

If someone from the clickhouse team is reading this, the slack link[1] on your community page seems broken [2]

[1] https://clickhousedb.slack.com/join/shared_invite/zt-nwwakmk... [2] https://clickhouse.tech/#community

This looks really cool! Particularly for the embedded analytics use case.

Do you have an example of how this would work on the front end with relationships. For example if I want to fetch posts and their comments how would the front code look like?

Not a general solution, but with Hasura, one approach we have seen is to use Postgres views to keep the old graph around as your data model changes.

In general API evolution is tricky and perfect decoupling between API clients and servers not possible (the article talks about this). What one can aim for is a combination of:

1) Adding new query parameters should not break clients 2) Adding new fields to the responses should not break clients 3) Adding new serialization formats (for newer clients) should not break existing clients

#1 & #2 is roughly what you get with GraphQL optional fields.

Phil Sturgeon has good articles on API Versioning[1] and Evolvability[2] for REST API's

[1] https://apisyouwonthate.com/blog/api-versioning-has-no-right... [2] https://phil.tech/2018/api-evolution-for-rest-http-apis/

(Author here) Couldn't agree more on not turning technology choices into religious devotions.

It is of course completely possible for you to build a query language from grounds up. django-restql seems to be doing this. Sparse fieldsets and Netflix Falcor other alternatives I've heard of. GraphQL however has good tooling and if you do see the need for a query language on top of your APIs using it is a good choice IMO.

GraphQL does not necessarily mean you have to throw away your existing backend and rebuild from scratch either. It's perfectly fine to use GraphQL as an additional API endpoint alongside existing APIs. A model we are seeing evolve with Hasura is to use Hasura for all the reads and delegate writes via the Actions framework either to a serverless function or another HTTP service.

(Author here)

You are right about REST not necessarily replicating the N + 1 Query problem. ORMs have already provided solutions for this problem. See https://guides.rubyonrails.org/active_record_querying.html#e... for example.

Looking at GraphQL as being a media type for REST misses the point because:

1) If you were to build a system that primarily used GraphQL for communication, you would be breaking the spirit of uniform resource constraint. Since the URI is the resource for REST, you would be having exactly 1 resource. The article talks a bit more about this. 2) The value add from GraphQL is primarily faster (and more efficient) front end development. So the question is do you want to implement the GraphQL media type?

Typed vs non typed interfaces are a personal preference. Typing adds safety but historically made getting started harder. That has changed in the recent years though as tooling has significantly improved.

I've talked about sparse field sets in the article. They are an alternative, but any form of query language requires a parser and implementation in the backend and GraphQL has good tooling for this.

On the third point of N + 1 queries: Hasura compiles the sql query where possible and otherwise uses a batching technique for external APIs, similar to haxl.