Built With MongoDB: Threader

Manuel Meyer
November 4, 2020 | Updated: October 17, 2022
#BuiltWithMongoDB #Startups

In 2020, we are bombarded by information from thousands of sources. Although this affords everyone the opportunity to stay on top of trends, opinions, and market data, it can be challenging to filter out relevant insights from the noise. In particular, developers and founders have thousands of sources of knowledge and information at their fingertips but need to cut through to the essential messages quickly to make game-time decisions on product development and business strategy.

In this post of the #BuiltWithMongoDB series, we sat down with Vincent Denise, CEO and co-founder of Threader, to discuss the company’s rapid growth and experience working with MongoDB. Threader is the first iOS Twitter client to read and bookmark tweetstorms, also known as “threads.” It helps Twitter users to read long-form tweets in an article format so they can consume the content without distraction.

Let's start at the beginning. How did you come up with Threader?

Back in 2017, my partner Marie and I left Paris to become digital nomads. We were closely tracking trends in content and became certain that threading on Twitter was not a phase but rather an integral new way to communicate in the age of microblogging.

People we talked to were looking for an alternative reading experience. At the time, the Twitter UI was different and tweetstorms were hard to read natively. We decided to build an iOS prototype featuring interesting content in this format, allowing users to convert Twitter threads in an article format, and bookmark them.

Fortunately, Threader was spotted by Chris Messina (inventor of the hashtag). He motivated us to launch on Product Hunt, and Apple featured us as an App of the Day. These two events boosted our visibility.

Since the beginning, we have bootstrapped Threader. We are a team of two and there are only 24 hours in a day, so we have to be wise about how we manage our time and the way we define our priorities.

How did you choose to build with MongoDB?

Before becoming an entrepreneur, I was a developer for a Parisian agency. One of the projects I worked on was an immersive game for a French television channel. We needed scalability and high performance, which brought me to learn more about NoSQL. I was switching programming languages and started to code with Node.js. MongoDB was often presented as a good pair to manage databases. At the time, I also read about MongoDB helping Foursquare with auto-sharding. MongoDB seemed to answer my needs and to be a perfect fit, which led me to implement it for the first time. Since then, it’s my go-to solution and I used it in a range of projects.

When I started building Threader, I knew that our database would grow beyond the scope of our previous projects. We wanted the ability to manage large amounts of data easily, and MongoDB seemed like the obvious choice for scale while maintaining flexibility to accommodate the continuous delivery of new app features.

We use database clusters on MongoDB Atlas, the fully managed and automated cloud service. With Atlas, time management is reduced and it’s reliable in the long term; I don’t have to be worried about the scaling issues. I know Threader’s infrastructure is between good hands and that Atlas always keeps an eye on production.

We also need to provide fast and efficient access to search more than 2 million threads, so we make use of MongoDB’s secondary indexes to give our users incredibly fast performance. We constantly measure engagement, so MongoDB Charts gives us an easy way to visualize complex data and allows us to track user growth and threads stored.

How has the MongoDB for Startups program affected Threader and your product's journey?

As every founder knows, the startup journey is stressful — especially for indies, since we mostly rely on our paid users to earn an income. To establish a stable infrastructure that can provide such a crucial role in our livelihood, we turned to MongoDB for Startups.

Technical advice from MongoDB saved us a lot of time, especially when we encountered unexpected growth issues. We had thousands of visitors on our website regularly, so we needed quick debugging support, which MongoDB consistently provided. I learned a lot from the program, and made valuable connections across the community.

Looking to build something cool? Get started with the MongoDB for Startups program.

← Previous

MongoDB Atlas Arrives in Italy | MongoDB Atlas Arriva in Italia

We’re delighted to announce our first foray into Italy with the launch of MongoDB Atlas on the AWS Europe (Milan) region. MongoDB Atlas is now available in 20 AWS regions around the world, including 6 European regions. Milan is a Recommended Region , meaning it has three Availability Zones (AZ). When you deploy a cluster in Milan, Atlas automatically distributes replicas to the different AZs for higher availability — if there’s an outage in one zone, the Atlas cluster will automatically fail over to keep running in the other two. And you can also deploy multi-region clusters with the same automatic failover built-in. We’re excited that, like customers in France, Germany, the UK, and more, Italian organizations will now be able to keep data in-country, delivering low-latency performance and ensuring confidence in data locality. We’re confident our Italian customers in government, financial services, and utilities in particular will appreciate this capability as they build tools to improve citizens’ lives and better serve their local users. Explore Atlas on AWS Today   In Italian, courtesy of Dominic: Siamo lieti di annunciare la nostra espansione in Italia rendendo disponibile MongoDB Atlas nella regione AWS Europa (Milano). MongoDB Atlas è ora disponibile in 20 regioni AWS nel mondo, comprese 6 regioni europee. Milano è una Recommended Region ; questo significa che ha tre Availability Zones (AZ). Quando viene creato un cluster a Milano, Atlas distribuisce automaticamente le repliche sulle diverse AZ per aumentare la disponibilità e l’affidabilità — nel caso in cui avvenga un disservizio in una zona, il cluster Atlas utilizzerà la funzionalità di failover per restare in esecuzione sulle altre due. Eventualmente è anche possibile creare cluster multi-region che incorporano la stessa logica di failover automatico. Siamo felici che anche le realtà italiane possano scegliere, come i nostri clienti in Francia, Germania, UK, ed altrove, di mantenere i propri dati all’interno dei confini nazionali, dando risposte a bassa latenza ai propri utenti ed assicurando loro la fiducia nella localizzazione fisica dei dati. Siamo sicuri che i nostri clienti in Italia, in particolare nel settore pubblico, nei servizi finanziari, e nelle utilities, apprezzeranno queste nuove possibilità per la creazione di nuovi strumenti per migliorare la vita dei cittadini e servire meglio i loro utenti in Italia. Scopri subito Atlas disponiblie su AWS

November 4, 2020

Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024