mbroecheler

7 ms·

1.
Show HN: Acorn.js – Turn GraphQL APIs into Tools for LLMs and Agents(github.com)
1 points by mbroecheler 1y ago|0 comments
2.
by mbroecheler 1y ago
Exactly, any generic GraphQL server can be turned into a set of LLM tools with minimal overhead and complexity.
3.
by mbroecheler 1y ago
Second that. A lot of our use cases are "remote tooling", i.e. calling APIs. Implementing an MCP server to wrap APIs seems very complex - both in terms of implementation and infrastructure. We have found GraphQL to be a great &quo
4.
by mbroecheler 2y ago
I agree that being able to write one piece of code that solves your use case is a big benefit over having to cobble together a message queue, stream processor, database, query engine, etc. We've been playing around with the idea of a b
5.
Show HN: Retrieval Augmented Generation for LLMs from APIs with Function Calling(github.com)
3 points by mbroecheler 3y ago|0 comments
6.
Personalized Search with Vector Embeddings for Semantic User Profiles at Scale(datasqrl.com)
2 points by mbroecheler 3y ago|0 comments
7.
by mbroecheler 3y ago
Totally agree with the motivation - it is too cumbersome to stitch all these cloud services together by hand. Another project that's similar in motivation but focused on cloud data infrastructure is https://www.datasqrl.com&
8.
SQRL: Enhancing SQL to a High-Level Data Language(datasqrl.com)
2 points by mbroecheler 3y ago|0 comments
9.
by mbroecheler 3y ago
You are totally right. We did not want to create a new language and we are trying to keep it as close to SQL as possible. The problem is that SQL lacks streaming constructs you need for temporal joins or creating streams from relational tab
10.
by mbroecheler 3y ago
Exactly, there are so many amazing dataflow engines, stream processors, and databases out there. We are not competing with those. We are trying to "compile away" all of the data plumbing code you have to write to integrate those s
11.
by mbroecheler 3y ago
Yes, the idea to maintain materialized views based on standing queries to make the queries instantaneous is the same. In addition, DataSQRL handles the ingest (e.g. consuming events off a queue, pre-processing the data, and populating the d
12.
Uplevel database development with DataSQRL: A compiler for the data layer(datasqrl.com)
4 points by mbroecheler 3y ago|7 comments
13.
by mbroecheler 3y ago
We'd love for you to join us in building a high-level data development language to simplify data-driven application development.
14.
by mbroecheler 11y ago
I suppose our communication around Titan has caused some confusion after the acquisition by DataStax. As one of the Titan devs I can say that we have no plans to abandon Titan. What we were trying to say is that we will have less time to de
15.
by mbroecheler 11y ago
Take a look at Gremlin 3 - it now supports both declarative and imperative queries. In fact, you can even mix and match the two. You want to match a complex pattern? Use declarative Gremlin so the query optimizer can figure out the best exe
16.
by mbroecheler 12y ago
Yes, it works :-) Support for multiple storage backends gives Titan a lot of deployment flexibility and allows it to inherit some great features like multi DC support. Software component reuse is pretty standard these days. What lead you to
17.
by mbroecheler 13y ago
Approximately $63 per hour on Amazon EC2.
18.
by mbroecheler 14y ago
I think you are looking at a very different use case here. The systems that I think you are referring to analyze a static graph representation. The Graph500 benchmark in particular loads one big static, unlabeled, undirected, property-free
19.
by mbroecheler 14y ago
Absolutely, without NoSQL solutions like Cassandra Titan would not be possible. Regarding Zookeeper: We actually build a locking system into Titan that uses quorum reads/writes with time-outs and cleanup to ensure consistency for certain ed
20.
by mbroecheler 14y ago
Hey, - the data we used was crawled by Kwak et. al in 2009. We wanted to use a real social network dataset for the experiment and that was the largest/most useful one we could find. Other than de-duplication we did not make any modification