I had a lot of fun “long tail whackamoling” our way through edge queries that our model of “this is eligible for a read replica” wasn’t accurately catching. Honestly just one of those “keep reading traces and working through them” development processes that just keeps drive a graph down and to the right.
Building higher-touch AI products that are applicable across the entire customer base of an existing enterprise SaaS provider on release does feel impossible.
It's very obvious when you look at the AI companies that have 'exit-velocity' in this space that they are playing in that they are either one of the following:
1. Targeting a need within that org that's narrow enough to be MVP-able enough across a diverse customer base
2. Targeting IC work directly
As we add more complexity here, it's going to be a long, long slog to market - even with model advancements.
We recently released our On-call product, and as part of that, had to think a lot about redundancy and 'failing safety'.
Here's how we achieve it - and how we're thinking about it. Interested if any other examples of this exist in the wild - I'd love to know more about how eg: Datadog achieve this.
We recently released our On-call product, and as part of that, had to build a mobile app.
We'd noticed there's been some debate recently regarding React Native, and if you can build 'native tier' apps using it. We'd seen a lot of this but as part of an initial hackathon tried Explo / RN / Nativewind and were completely blown away by both the quality of app we could produce and the developer experience that let us do this quickly.
If anyone's in this space / thinking about making a technical decision here I couldn't recommend this stack strongly enough!
Were Prequel using RaabitMQ to stay cloud platform agnostic when spinning up new environments? Always wondered how companies that offer managed services on the customers cloud like this manage infrastructure in this regard. Do you maintain an environment on each cloud platform with a relatively standard configuration, or do you have a central cluster hosted in one cloud provider which the other deployments phone home to?
Having the type system this complicated is mostly for library builders, makes the developer experience of tools like tRPC, Zod and Prisma possible. An engineer writing business logic in TypeScript will probably never have to learn how to write (or even read tbh) complex TypeScript signatures, but benefit significantly from the solutions the type system complexity is a necessary precursor for.
I think it makes sense in the context of the poential of plain old SQL (and additions such as dbt) winning out vs Python or other general purpose programming solutions as the analytics workbench (although this is controversial, there's a school of thought that backs it).
Totally agree - in fact from the issues pages it seemed like there had been a conscious decision from Airbyte not to support a Terraform provider and instead build out Octavia, which as you say leaves a lot to be desired. Deploying Airbyte is still far too hard, I'd be happy to pay for an 'on prem' version like Gitlab where it's a bit more managed. I also think the failure modes for Airbyte on prem are too hard to debug in comparison to other data 'MDS' tools.
Switched to Fivetran after experiences with Airbyte, operating Airbyte was extremely tedious, even primetime connectors had bugs that I personally had to fix, we keep Airbyte around for the "long tail" of SaaS tools that Fivetran doesn't have a connector for but managing an Airbyte deployment in a stable manner for the long term was not easy.
It is popular in newgen tooling but I feel its more a function of the slowness of `tsc` than anything else. I get why `tsc` is slow, and have a lot of respect for the team and the constraints they work under but I can't help but feeling if we were to get a faster type checker (potentially `stc` from the creator of `swc` which also does this? https://github.com/dudykr/stc), this choice would be less popular. However if I'm honest I don't know if TypeScript's type system means that there are some natural constraints on how fast it can be validated.
Those algorithms and improvements in large data processing got bundled away into a platform/infra layer a developer or user interfaces with unaware of what's going on in the background to produce the results they want.
Hosting any significantly scaled CI/CD system is very difficult work and since every team in your organisation usually touches it you often have a large blast radius. I've seen downtimes take a long time to recover from even when self hosted, compliance is also hard. It's a good candidate for SaaS IMO.
If you drop a 'title' column from a users table, for example, you can revert and have the title column reappear with the dropped data, new users added during this time (while the column was dropped) will not have a title.