MongoDB Applied
Customer stories, use cases and experience
Built with MongoDB: Gryphon Online Safety
As friends and coworkers at an IoT company, John Wu and Arup Bhattacharya used to commiserate about the perils the internet posed for their children. It’s a problem most parents can relate to—especially now, when some children spend more than seven hours a day online. One day, John’s daughter saw something online that horrified him, and he and Arup decided they wanted to help bring the internet back into the hands of parents so they could curate online content for their children. With that, Gryphon Online Safety was formed. Gryphon is a cloud-managed network protection platform for homes and small businesses that blocks viruses, malware, and hackers while giving parents the chance to filter content and monitor what their children are doing. With $5.4 million in seed funding, more than 30,000 customers, and a team of 30 employees across three countries, Gryphon is growing quickly. The COVID-19 pandemic further accelerated adoption of Gryphon’s products; with children spending more time on devices at home and hacking activity increasing online, the company has seen a significant boost in users. In this edition of #BuiltWithMongoDB, we talk to CTO and Co-Founder Arup Bhattacharya and Senior Cloud Solutions Architect Sandip Das about the future of internet security and their experience building Gryphon with MongoDB. MongoDB: How has your business changed during COVID-19, given that families have been spending more time at home and online? Arup Bhattacharya: Our business has thrived during COVID. Although we typically add a thousand customers every month, during the pandemic that number has skyrocketed. More people are working from home and more children are attending virtual classes, which has caused families to think more about security and parental controls. Although we typically see two main cycles with our business, one in August and the other around the holiday season, our product isn’t that cyclical. People upgrade their hardware at different times, and when they look for high-performance mesh WiFi routers and security, we are an obvious solution. What’s funny is that while parents deeply appreciate our solution and the security it provides, children often hate us. I stumbled across a Reddit post in which a child wondered how he could get past the access filters his father had set up via Gryphon. Someone responded: “There’s nothing you can do but grow up and buy your own router.” With that said, there’s so much bad content out there—from bullying to games that hurt children—that it’s crucial we allow an easy way for parents to control the experience their children have online. MongoDB: At what point did you implement MongoDB, and what decision framework and criteria led to that decision? Sandip Das: We compared the big databases in terms of what solutions were available. We wanted something freely available for rapid prototyping and that made integration easy. For the back end, we use JavaScript with Node.js runtime, which is easily compatible with MongoDB. In fact, it’s the default choice for database integration. MongoDB owns its library, and combined with how simple the integration was, this made MongoDB a good choice for us. Another big factor was the storage. With MongoDB Atlas, you can have any number of servers, and you can quickly scale up to whatever your demands are. We developed the service from the beginning, and we were managing it ourselves. However, as the load has increased and more customers came on board, we thought it was time to seek out a better and more scalable solution that’s also easy to manage. That’s how we found MongoDB Atlas. With MongoDb Atlas autoscaling, we were able to achieve the flexibility we always wanted, along with automated backup solutions. MongoDB: Arup, you've held several senior engineering positions before becoming Co-founder and CTO of Gryphon. What advice would you give to others looking to follow that path? AB: The CTO position is very critical because it is the bridge between technology and business. The first thing you should think about when starting a company is the pain point you are solving. We started by first asking ourselves how our product will help society. How will it help people improve their lives? The starting point of a company shouldn’t just be to make money overnight. What will keep you motivated through the difficulty of building a business is thinking deeply about how your product will make a positive impact on people’s lives. Second, there inevitably will be low times and high times. At several points in the founder’s journey, you will experience real doubt and wonder whether you can really achieve your goals. The best thing to do is to keep on pushing for the highest-quality product possible. If your product is the best on the market and you are solving a genuine problem, the customers will find and appreciate you. Looking to build something cool? Get started with the MongoDB for Startups program.
Built with MongoDB: ADEx
Anyone who has reviewed legal documents knows how tedious and time-consuming the process can be. In the high-stakes, detail-oriented legal environment, even experienced lawyers or paralegals can make mistakes. And those mistakes can be expensive. Enter ADEx . ADEx is an online legal document due-diligence platform that is transforming the way people interact with legal and financial documents. “Computers never get tired, no matter how many pages your legal document contains or how dense its language,” says ADEx Co-Founder and CTO Apoorv Khandelwal . “Our platform can abstract your legal documents faster and more reliably than a paralegal.” The company has hosted more than 7 million contracts and partnered with large companies including Salesforce, Box, and Colliers International. As part of our #BuiltWithMongoDB series, we spoke with Apoorv about the company’s growth, its tech stack, and his experience scaling with MongoDB. MongoDB: What's ADEx's tech stack like? Apoorv Khandelwal: For our back end, we use the Java-based Play and Spring frameworks. We use Angular for the front end and Electron for the desktop app. For various predictions, we have Python Flask applications, and the deep learning models themselves are trained with TensorFlow and Keras. Our cloud provider for servers and application deployment is Kubernetes. We use various AWS services for storing clients’ legal documents, machine learning models, and other files. But the majority of our application data — ranging from contract summaries to our provision library to user events — is stored in MongoDB. MongoDB: How did you decide to use MongoDB? AK: Having worked at Amazon as a software development engineer, I was familiar with SQL databases and Hadoop. The team focused on machine learning, so its input data formats and sources were constantly evolving. My experiences showed me the pain associated with keeping SQL schemas up to date. When the choice came for ADEx, it was clear to me that we couldn’t use SQL. My experiences in successful startups showed me how we could successfully leverage the flexibility and scalability of MongoDB. I had worked before with Dynamo and other NoSQL platforms, but we didn’t want to get tied down to specific cloud providers. There were conversations about graph databases such as Neo4j as well, but they were not ideal for the majority of our queries that execute bulk data scans or do not start from a known data point. In the end, MongoDB’s flexibility and large community support made it the best choice. Later, upon joining the Techstars Accelerator in 2019, we were able to get credits through the Techstars and MongoDB for a startups partnership. We worked with a technical advisor at MongoDB to set up private connections from our applications. The learning curve was very short compared to other databases I had used; the basic concepts were clear, and the documentation guided me through the more complex data modeling and architecture decisions. Between features such as end-to-end encryption, auto-scaling, and automated backups, much of the basic database management work is now handled by MongoDB Atlas. MongoDB: How has MongoDB been for you as you've scaled? AK: With Atlas, I don’t have to worry about scaling anymore. Given how intuitive and easy to use it is — especially with the metrics and visualizations — it has solved a bunch of problems. I don’t even have to think about storage, because the database capacity automatically adjusts based on current data usage. Often for SQL, a team of database engineers may be needed for managing and running the database. With Atlas, we don’t need any dedicated person at all. We’ve been pleasantly surprised by the gentle learning curve while gradually utilizing more MongoDB features. For example, as we’ve introduced more-sophisticated use cases in our products, and we have enjoyed using MongoDB’s powerful aggregation framework to offload data processing from our application servers. We have an M30 cluster for cloud, and M20 for QA. MongoDB: What advice do you have for developers hoping to someday become CTOs? AK: Three things. First, get prior experience at a successful startup with a small engineering team. You will witness firsthand the growing pains a CTO has to deal with. These practical lessons can be invaluable for your own venture. Second, act as a filter between the business and technical teams. Imagine filling a small plate with food from a giant buffet. In a startup, the technical team has a limited capacity with which to build features or maintain the product. You should actively filter the flow of incoming ideas and features. Prioritizing the most crucial ones will prevent overflowing the technical team’s capacity while ensuring maximum value for customers. And third, get good technical mentors. It’s difficult to design sufficiently abstract data models that anticipate all potential future pivots. But a good debate with mentors can save plenty of technical debt later on. The first years were hard for me until I got technical mentors, such as Lalit Kapoor and Mihai Strusievici through Techstars. Looking to build something cool? Get started with the MongoDB for Startups program.
Built With MongoDB: Workast
In 2016, Guillermo Gette was a technical lead at Expedia focusing on the front end development of its Australia and New Zealand websites. Like so many others, he was using Slack to communicate with team members. While Slack enabled rapid and collaborative communication, it didn’t do much to keep his team organized. So Guillermo kept a notepad close by to write to-do lists based on Slack messages, as well as a spreadsheet to manage developer tasks. But Guillermo soon realized that this practice made no sense. Why couldn’t he just put all these lists in Slack? Guillermo first built a simple bot that put a to-do list inside a Slack conversation and then published the app in the Slack Marketplace. Encouraged by growing demand from users interested in his tool, Guillermo founded Workast , a full-featured project management system embedded in Slack that is used actively by more than 50,000 people at companies large and small. Workast has raised $1.85 million from investors Greycroft Partners, Spider Capital, Mucker Capital, and Dream Incubator. In this #BuiltWithMongoDB story, Guillermo shares his vision for Workast and what he’s learned along the way. Before you started Workast, you were just trying to solve the problem for yourself. Let's talk about how you got started. In 2016, Slack was still an early-stage startup, and it was becoming quite popular in the tech community. I realized I could save a lot of time if I had a simple bot inside of Slack that captured to-do items from Slack conversations and created an environment inside of Slack to organize and communicate about projects. At the beginning, I was really putting my skills as a software developer to work to just build something for myself. The initial idea was to quickly capture a part of a conversation and turn it into a to-do item. Then you could seamlessly move from Slack into Workast and manage lots of different to-do lists to get work done. But once I saw how people used Workast, it became clear that for smaller organizations, the app became how the whole company ran. And for larger companies, Workast organized the work in (and eventually across) departments. People were drawn to the fact that they didn’t have to keep switching between communication and collaboration to project management. You didn’t have to invite people to join a project. They were there already because they were in Slack. What were some of the challenges you faced early on? When I put the app on the Slack marketplace, it took off right away and then two things happened. First, I got questions about new features. People wanted more ability to organize the tasks, tag them, and report on them in the Slack channel from which they originated. We started improving the product as fast as possible based on user feedback, and that led to more traction. The second thing that happened was we realized we were in a red ocean market, which means lots of players. People have used many of the mature project management and to-do apps out there and have high expectations. Our advantage in one sense was that we were embedded in Slack. In another sense, we were playing catch-up from the minute we went live. People loved the app, but then they’d also say, “Hey, I also need sub-tasks, assignments, projects, and deadlines.” They wanted templating, repeated tasks, tagging, advanced reporting, visualizations, commenting, and search, all the stuff they were used to. There is a lot of functionality that doesn’t sound exciting, and it doesn’t sound innovative, but people really wanted it in our product, and we had to build it quickly. Reducing the time from idea to implementation was crucial. There's a moment in every entrepreneur's journey when they realize that their product can become an actual company. When did it feel like you had a real business on your hands? At the beginning, it was mostly individuals and startups. Then, the Slack marketplace opened the door to a lot of other companies. Teams at Expedia, IBM, PayPal, and MongoDB started using Workast too. It was clear that we had hit a chord across a large market. The arrival of bigger companies was good news, of course, but also a challenge because we had to pass reviews by security, IT, and procurement, which means lots of work attending to certifications, documentation, and integrations. We then had to figure out how to build a business and capture the value we were creating. Pretty quickly, people started asking when we were going to start charging. They saw the value and expected they would have to pay for it at some point, which was a good sign. Our strategy was to focus on product-led growth. We decided not to focus on revenue but to allow people to use the product and eventually realize that upgrading made sense. So we don’t have a 30-day trial but rather we put counters on certain features: you can use them 10 times and then you are asked to upgrade. Why did you decide to build Workast on MongoDB? When you start a company, you don’t really know where your product — or your customers — are going to take you. You want the cost of change and evolution to be as low as possible. You want to move fast. That makes MongoDB, a schema-less database built for flexibility and experimentation, the right solution. The cool thing is that as our company and our product have evolved, our database has evolved with us. We’ve never had to suffer downtime to update schemas or write migration scripts. Time to market was crucial for us, and MongoDB accelerates that. MongoDB also scales and keeps on scaling. More than five million tasks have been created in Workast. Those tasks have to be actively there, they have to be searchable, and they have to be indexed. We don’t need to worry about it. We use MongoDB’s Performance Advisor every week, which tells us about performance problems and helps identify missing indexes, helping us make sure we’re scalable. Right now our cluster doesn’t need sharding, but when we do, it’s there for us. MongoDB is a database we can rely on — now and as we grow. What features of MongoDB have proven to be most helpful? Our architecture is based on Node.js and the AWS Lambda serverless platform. We use MongoDB’s in-database triggers to both automate actions in the database and also call out the Lambda functions. Our database is growing and now we have users that have years of data in Workast. We realized that at some point, we will probably want to move older data out of production into an archive. Again, MongoDB has a plan for moving data to object storage in a data lake but still allowing it to be searchable. When we need it, we will use it. We use MongoDB Atlas, so everything is hosted by MongoDB in the Cloud, run by MonogoDB, with lots of automation. Operations are really simple from our point of view. Our goal is to offload responsibility for everything that doesn't drive differentiating value. Uptime and scalability matter but we can push a lot of that responsibility to the Cloud. We think about MongoDB as much as we want to. Not more. MongoDB acts as our database administrator, making sure the servers are updated so we can focus on building our software and business. Looking to build something cool with MongoDB? Get started with the MongoDB for Startups program.
Built With MongoDB: Stoovo
When Hantz Févry and Pierre Mombeleur first met, they wouldn’t have guessed they’d one day become co-founders. As students at the same high school in Haiti, they weren’t particularly close. There was no noticeable chemistry when they faced off in a music competition either, and they maintained only a passing acquaintance on Twitch. But both attended college in New York. At the time, Hantz’s checking account was constantly overdrawn, and it was harder than he thought to pick up short-term work. He and Pierre started talking about ways to help gig workers maximize their income by providing intelligence about how and when to use platforms such as Uber and DoorDash. They kept working on that idea even as both got jobs at Google. In 2015, the pair met Semih Korkmaz, who became their CTO, and in 2018 they launched Stoovo , an app to help gig workers maximize their income. Stoovo now covers 6,000 platforms used by gig workers to find jobs, and has 17 employees. Just last week, the company announced that it had raised a $2.4 million seed round from 500 Startups, Alpana Ventures, Plug and Play Ventures and Watertower Ventures. In this edition of #BuiltWithMongoDB, we talk to the Stoovo team about building for the gig economy, immigrant entrepreneurship, and their experience growing with MongoDB for Startups . How did you keep Stoovo going while you were at Google? Hantz: There is a big misconception among venture capitalists that you need to be working full-time on your startup. That is not true in the case of immigrants. I’m an immigrant, and don’t have my aunt’s couch to sleep on. I don’t have this famous garage in Silicon Valley. So I basically had to work two full-time jobs. After working until 5 pm for Google, I started working with Semih, often until three or four in the morning. What is your vision for Stoovo for the next few years? Hantz: You have three main players in the gig economy: the platforms, the requester, and the supplier. The problem is that the worker, or the supplier, is left completely alone, because the platform is optimizing to meet the demand of the requester. We want to shift that optimization to help workers maximize their income for each hour worked. We want to give them financial stability through income boosting and income smoothing. Without Stoovo, workers are on their own trying to figure out if their time is better spent on DoorDash or Uber Eats or Postmates. They realize that if they blindly follow the direction of those platforms, they may not make enough money. The average gig worker uses three platforms, and shuffles arbitrarily between them, or relies on word of mouth, which is not really optimal. We tell gig workers which platform is best for them at any given time, and when to take a break. We go even further to help with financial management. We envision another type of banking for gig workers, where we not only store the money, but we’re better adapted to their realities. How does the typical gig worker use Stoovo? Hantz: We have one user, Lionel, who is an actor and does gig work to help ends meet. Without Stoovo, he was trying to use Uber sometimes, sometimes Postmates. Sometimes he made money, sometimes he didn’t. With Stoovo, he knows exactly how to shift between his acting career, and exactly what to do and how many hours he needs to work. Another user might rely more on the finance side. We have one user, Megan, who relies on the card for a cash advance. At first we were thinking that gig workers would use the cash advance to pay for gas. But when we looked at the transactions, a lot of them were fast food. Megan explained that gig workers often don’t even have a sufficient cash flow to buy food. This is why we built the two products together. We help you plan your day to maximize your income and we provide you with cash flow if needed. How have you built your tech stack to enable this? Semih: Stoovo is a very distributed system and works with many different partners, especially geospatial data providers, so our stack is a little bit heterogenous. On the application side we use Node.js, and MongoDB is our database platform. On top of that, of course, we have lots of Python scripts running. How did you select MongoDB as your database solution? Semih: We did a few prototypes with relational databases, but there were so many changes – not only on our side, but at our data partners – that we weren’t able to stick with a schema. And changing the schemas in our applications was almost completely eliminating our chances to work in an agile manner. We were really impressed with some of the capabilities of the graph databases, but you can always represent a graph in a document format. That’s when we realized we would go with NoSQL. After that, it was easy to choose MongoDB. What has it been like scaling with MongoDB? Semih: MongoDB Atlas made our life much, much easier. If you’re a startup, when you first start with a database, you want to start small. You have to keep your costs under control and your maintenance low. Then you need to scale up, and you see many startups fail to do this. Thanks to Atlas’ sharding system and its scaling system, which is automatically handling each replica’s scaling, we were having no problems at all with this, and we were easily able to scale. What are some of the features of MongoDB you find most valuable? Semih: We are rapidly developing many machine learning models, and they can be changing all the time. Those can create a new collection or change an existing collection, and change the access patterns. When this happens, indexing becomes really important. MongoDB Atlas helps us in two ways. One is that it gives us real-time alerts when our interaction pattern has changed. And, it suggests what the index should be. Then we can say, “Yes, please go ahead,” and apply this index on a rolling basis, and that makes life really easy for us. There is so much happening in the gig economy. What are your thoughts on how Stoovo fits into the future of the sector? Pierre: There’s an increasing amount of pressure for platforms to make sure workers’ rights are respected. We want companies to really give workers context into their work and be able to use data to their advantage, rather than holding onto the data and only using it themselves. Hantz: If you talk to someone from Gen Z, they don’t see themselves working for a big corporation from nine to five. There will also be a lot of automation and a lot of displacement of jobs. So a lot of people will jump into the gig economy, and they’ll need two things: They’ll need to make sure they earn enough, and they will need a financial system built for gig workers. This is exactly where we’re trying to position Stoovo. Looking to build something cool? Get started with the MongoDB for Startups program.
Built with MongoDB: Journey Foods
Serial entrepreneur Riana Lynn has been building the future of food for more than a decade. While in graduate school and researching data and genetics at the University of Chicago, she launched one of the nation’s first juice bars which gave her an inside look at the supply chain issues plaguing the raw food industry. After that, Riana continued innovating in the sector: She built and sold two other companies, worked in venture capital, and, in 2018, launched her most ambitious startup yet – Journey Foods , a machine learning-powered software platform for food companies. Just three years after its official launch, Journey Foods has raised $2.5 million from investors across three continents. It has partnered with global consortiums such as Future Food Network at Stanford, FoodTank, and University of Chicago on sustainability and data, and it now has more than 130 companies as customers, including Ingredion, one of the world’s largest ingredients companies, and Unilever. For this edition of #BuiltWithMongoDB, we speak with Riana about food technology, scaling an artificial intelligence platform, and the future of food. You have worked in food tech for most of your career. What specifically inspired you to start Journey Foods? While I was working in venture capital, I wanted to find a product that could help us track an unprecedented amount of data about food: everything from optimizing the supply chain to price and nutrition. We ended up building it ourselves using Google spreadsheets and a few APIs. I presented some of our early work in March 2019 to 1,500 food companies at a conference in San Francisco. Some of them asked us if we could apply our algorithms to their food products and work with their internal teams. That’s when we decided to take our work and turn it into a SaaS offering, and Journey Foods was born. There are so many problems we need to tackle to provide everyone with healthy and affordable food. What's your vision for Journey Foods? We consider ourselves a technology company for the food industry—whether you are trying to source ingredients, optimize your supply chain, or get consumer insights as to how your product will perform in the market. We aspire to be the leader for integrations in the food industry. We’ll be able to provide additional services that will help our customers scale and improve their portfolios much faster. Right now we are trying to focus on developing our service to accurately provide nutrition insights, sustainability insights, and help save our customers money. We are prioritizing partnerships that will help us build out a big and dynamic ecosystem. How did you decide to start building with MongoDB? I wanted to make sure we could create something that was scalable, not only for startups but also for enterprise customers. In the first six months, we built the product on top of the Google Cloud Platform, a low-code app called Bubble, and a bunch of APIs. But our enterprise customers were using SAP and Microsoft Dynamics, and I realized that in order to provide offerings for these companies, we needed to have databases that could work at that same scale. We also needed better security for our customers, which is especially important in the food industry. We looked at the tools the best software and data companies were using. We didn’t want clunky integrations that slowed us down. We’re also a design-heavy firm, so we’re thinking about the user experience as well. Given MongoDB’s seamless user experience, ease of scalability, and stellar recommendations from other companies, we ended up building with MongoDB. What's your favorite MongoDB feature? This might not count as a feature, but the support and the follow-up we receive from MongoDB has been consistent and persistent. Our developers appreciate how easy it is to use the platform, and how seamless it is to share and collaborate on different things. We also take advantage of many of the webinars, courses, and training programs that MongoDB offers. We want to move into more automation, machine learning, and artificial intelligence functionality, and we’re interested in seeing how MongoDB will help us evolve in that direction. Looking forward to the next decade, what do you see as the biggest opportunities in the future of food? I see two things. One has to do with overall nutrition and chronic disease. Over the past few years, we’ve seen dire numbers on chronic disease in every country in the world. Food technology is going to help improve those numbers. Second is that with the pandemic, we went back to a lot of deleterious environmental practices in the supply chain, just so that we could meet demand in a quickly-changing world. The environment, along with affordability, is a very big interest both for companies and people. And we are bringing in data that is relevant to the biggest problems we see in the world with food, affecting the livelihood of people across the world. For us, our competitive advantage lies in being the one-stop shop that integrates across many markets and partners, and that can drive the most actionable experience for our customers so we can define the future of the food industry. Looking to build something cool? Get started with the MongoDB for Startups program.
Australian Start-Up Ynomia Is Building an IoT Platform to Transform the Construction Industry and its Hostile Environments
The trillion dollar construction industry has not yet experienced the same revolution in technology you might have expected. Low levels of R&D and difficult working environments have led to a lack of innovation and fundamental improvements have been slow. But one Australian start-up is changing that by building an Internet of Things (IoT) platform to harness construction and jobsite data in real time. “Productivity in construction is down there with hunting and fishing as one of the least productive industries per capita in the entire world. It's a space that's ripe for people to come in and really help,” explains Rob Postill , CTO at Ynomia. Ynomia has already been closely involved with many prestigious construction projects, including the residential N06 development in London’s famous 2012 Olympic Village. It was also integral to the construction of the Victoria University Tower in Australia. Link to Podcast Episode Here “These projects involve massive outflow of money: think about glass facades on modern buildings, which can represent 20-30 percent of the overall project cost. They are largely produced in China and can take 12 weeks to get here,” says Postill. “Meanwhile, the plasterer, the plumber, the electrician are all waiting for those glass facades to be put on so it is safe for them to work. If you get it wrong, you can go in the deep red very quickly.” To tackle these longstanding challenges, Ynomia aims to address the lack of connectivity, transparency and data management on construction sites, which has traditionally resulted in the inefficient use of critical personnel, equipment and materials; compressed timelines; and unpredictable cash flows. To optimize productivity, Ynomia offers a simple end-to-end technology solution that creates a Connected Jobsite. Helping teams manage materials, tools, and people across the worksite in real time. IOT in a Hostile Environment The deployment of technology in construction is often fraught with risk. As a result, construction sites are still largely run on paper, such as blueprints, diagrams and models as well as the more traditional invoices and filing. At the same time, there is a constant need to track progress and monitor massive volumes of information across the entire supply chain. Engineers, builders, electricians, plumbers, and all the other associated professionals need to know what they need to do, where they need to be, and when they need to start. “The environment is hostile to technology like GPS, computers, and mobile phone reception because you have a lot of Faraday cages and lots of water and dust,” explains Postill. “You can't have somebody wandering around a construction site with a laptop; it'll get trashed pretty quickly." Enter MongoDB Atlas “On a site, you might be talking about materials, then if you add to that plant & equipment, or bins, or tools etc, you're rapidly getting into thousands and thousands of tags, talking all the time, every day,” said Postill. That means thousands of tags now send millions of readings on Ynomia building sites around the world. All these IoT data packets must be stored efficiently and accurately so Ynomia can reassemble the history of what has happened and track tagged inventory, personnel, and vehicles around the site. Many of the tag events are also safety critical so accuracy is a vital component and packets can't be missed. To address these needs Ynomia was looking for a database that was scalable, flexible, resilient and could easily handle a wide variety of fast-changing sensor data captured from multiple devices. The final component Postill was looking for in a database layer was freedom: a database that didn't lock them into a single cloud platform as they were still in the early stages of assessing cloud partners. The Commonwealth Scientific and Industrial Research Organisation , which Postill had worked with in the past, suggested MongoDB , a general purpose, document-based database built for modern applications. “The most important factor was that the database is event-driven, which I knew would be difficult in the traditional relational model. We deal with millions of tag readings a day, which is a massive wall of data,” said Postill. A Cloud Database Ynomia is using MongoDB Atlas , the global cloud database service, now hosted on Microsoft Azure. Atlas offers best-in-class automation and proven practices that combine availability, scalability, and compliance with the most demanding data security and privacy standards. “When we started we didn't know enough about the problem and we didn't want to be constrained," explained Postill. "MongoDB Atlas gives us a cloud environment that moves with us. It allows us to understand what is happening and make changes to the architecture as we go." Postill says this combination of flexibility and management tooling also allows his developers to focus on business value not undifferentiated code. One example Postill gave was cluster administration: "Cluster administration for a start-up like us is wasted work," he said. "We’re not solving the customer's problem. We're not moving anything on. We’re focusing on the wrong thing. For us to be able to just make that problem go away is huge. Why wouldn’t you?" Atlas also gives Ynomia the option to spin out new clusters seamlessly anywhere in the world. This allows customers to keep data local to their construction site, improving latency and helping solve for regional data regulations. Real Time Analytics The company has also deployed MongoDB Charts, which takes this live data and automatically provides a real time view. Charts is the fastest and easiest way to visualize event data directly from MongoDB in order to act instantly and decisively based on the real-time insights generated by event-driven architecture. It allows Ynomia to share dashboards so all the right people can see what they need to and can collaborate accordingly. “Charts enables us to quickly visualize information without having to build more expensive tools, both internally and externally, to examine our data,” comments Postill. “As a startup, we go through this journey of: what are we doing and how are we doing it? There's a lot of stuff we are finding out along the way on how we slice and re-slice our data using Charts.” A Platform for Future Growth Ynomia is targeting a huge market and is set for ambitious growth in the coming years. How the platform, and its underlying architecture, can continue to scale and evolve will be crucial to enabling that business growth. “We do anything we can to keep things simple,” concluded Postill. “We pick technology partners that save us from spending time we shouldn't spend so we can solve real problems. We pick technologies that roll with the punches and that's MongoDB.” When we started we didn't know enough about the problem and we didn't want to be constrained," explained Postill. "MongoDB Atlas gives us a cloud environment that moves with us. It allows us to understand what is happening and make changes to the architecture as we go. Rob Postill, CTO, Ynomia
Appy Pie & MongoDB’s Seamless, No-Code Business Solutions for Mobile & Web Apps
The tech industry’s ceaseless and exponential growth is no longer a surprise. As long as clients and end-users remain interested in faster, more efficient services, then tech companies will continue to improve business processes to meet the demand. Simultaneously, these improvements will reduce costs and maximize revenue. It’s a win-win--if, of course, it’s done correctly. So, what’s behind most success stories? How do some companies launch and maintain applications at such rapid, expansive scale? Often, the key to success lies in fostering core business processes that are driven by automation. For many tech-based organizations, Appy Pie Connect has been the go-to seamless integration platform that helps them get started. And now, with MongoDB Realm , it’s about to get even easier. Users build best in-class-apps across Android, iOS, and web with MongoDB Realm’s mobile database, sync solution, and application development services. Why use Appy Pie & MongoDB Realm? Together, Appy Pie and MongoDB are driving seismic operational change. Originally, Appy Pie AppMakr product moved to MongoDB Realm for local storage. But after experiencing the immense ease and advantages offered by Realm--specifically, its offline-first database that supports cross-platform app development-- we decided to extend its benefits to the customers of Appy Pie Connect. As an automation platform, Appy Pie Connect helps businesses automate manual tasks through smart integrations, allowing for intuitive, instant sharing between apps less commonly connected like MailChimp and LinkedIn or Stripe and Gmail, and so on. By integrating MongoDB and MongoDB Realm with Appy Pie Connect, customers can easily store or retrieve data within multiple database sources. This enables the storage of flexible schemas and maintains consistency and integration. This unique “no code” technology allows organizations to extract and work with data from MongoDB and then apply that data to desired software through triggered-based actions. For example, users can set up a trigger for every event on their Google Calendar so that their Slack status corresponds and is updated at the start and end of each meeting. This way, data concurrency is maintained without any manual effort. Realm is a particularly great choice for the customers at Appy Pie Connect because of its effortless data syncing. View some of the common use cases below. Example 1 In the Meter Billing example below, cost is calculated in real time based on usage (e.g. video viewing time), resulting in a transparent “pay as you go” model. Example 2 With real-time data sync, any updates or changes to the application are immediately reflected without requiring users to update or reinstall. Example 3 All API failure logs are conveniently displayed to the admin on the Appy Pie dashboard so that immediate troubleshooting actions can be taken. Benefits of MongoDB Realm and MongoDB Atlas Appy Pie Connect already uses MongoDB Atlas, so moving to Realm -- a MongoDB product offered through Atlas -- was a natural choice. Realm allows mobile users to sync data quickly and seamlessly between mobile devices and backend systems, even if they go offline (sync will occur when they are connected) -- and Atlas enables it all.. Some benefits of using Atlas are as follows: Scalability flexible data schema Document oriented storage Ad hoc queries, indexing, and real-time aggregation Powerful tools for data analysis Serverless function and GraphQL support Easy hosting and quickly able to built rest API Ultimately, Appy Pie Connect helps businesses convert MongoDB into a central data store by pulling in and replicating data from all its sources. This allows customers to create new MongoDB documents automatically from new Typeform entries, new files on Dropbox, new posts on WordPress, or other resources. Similarly, Appy Pie Connect can also send MongoDB data to other third-party apps, including WordPress, Salesforce, Slack, Mailchimp, Google Drive, and many more. This makes enterprise-wide communication and collaboration much more efficient. When data is pulled from MongoDB through automation, it can help streamline other areas of the business. For example, when you pull MongoDB data into MailChimp, you can automatically add a new subscriber on Mailchimp. This ensures that your lists grow automatically, as fast as your business does. Ex. Appy Pie Connect seamlessly sends MongoDB data to third-party apps Use cases Send data from MongoDB to LinkedIn (without any code!) to quickly post accurate job-related content Extract retail product data into Google Sheets to record valuable data in an organized manner in one place Post enterprise-related content from MongoDB to Twitter to streamline social media presence How it works Appy Pie Connect employs a trigger-action based function that allows you, as a platform user, to choose the two apps you want to connect. The process is very straightforward. Once you choose the apps you wish to integrate, you will be presented with multiple options to connect them. Simply click on the “Connect” button. To integrate with the selected applications accounts, simply allow API access for Appy Pie Connect. Next, design the workflows by mapping all of your data synced from the applications you are connecting. Once complete, you are ready to test your brand new Connect with your Trigger and Action apps. And, that’s it! It is time to experience the magic of Appy Pie Connect at work. Let the automation workflows take over the mundane, repetitive tasks, and move on to more innovative, exciting tasks. As the efficiency of an organization improves through automation, one of the most direct advantages is a marked reduction in cost. These integrations help save hundreds of hours of manual effort, thereby freeing up talented resources to instead focus their energy and intellect on more critical, innovative issues. With Appy Pie Connect and MongoDB Realm, businesses can ensure that their workforce is not only optimized but also inspired, a key factor to employee satisfaction and overall company success. Watch this demo to learn how to integrate MongoDB with Google Sheets using Appy Pie Connect to help you automate data exchange between MongoDB and Google Sheets with ease. Click here to learn more about MongoDB Realm
Build Better Mobile Apps -- Running MongoDB Realm and Google Cloud
We’re partnering with Google Cloud to offer MongoDB Realm as part of the MongoDB Cloud stack with Google Cloud to service users globally whether you’re building a new mobile app or modernizing an existing one. Realm’s integrated application development services make it easy for developers to build industry leading apps on mobile devices and the web. With MongoDB Atlas running as a service with Google Cloud, it’s easy to connect your mobile database to Google services. Customers choose Google Cloud to: avoid vendor lock-in by running multi-cloud and hybrid cloud deployments take advantage of Google Cloud’s machine learning and advanced analytics abilities stay secure with the same protections Google Cloud itself uses to guard their data, applications, and infrastructure. Why MongoDB Realm for Mobile? Realm comes with 3 key features: Cross-platform mobile database Cross-platform mobile sync solution Time-saving application development services Mobile Database Realm’s mobile database is an open source, developer-friendly alternative to CoreData and SQLite. With Realm’s open source database, mobile developers can build offline-first apps in a fraction of the time. Supported languages include Swift, C#, Xamarin, JavaScript, Java, ReactNative, Kotlin, and Objective-C. Realm’s Database was built with a flexible, object-oriented data model, so it’s simple to learn and mirrors the way developers already code. Because it was built for mobile, applications built on Realm are reliable, highly performant, and work across platforms. Sync Solution Realm Sync is an out-of-the-box synchronization service that keeps data up-to-date between devices, end users, and your backend systems, all in real-time. It eliminates the need to work with REST, simplifying your offline-first app architecture. Use Sync to backup user data, build collaborative features, and keep data up to date whenever devices are online - without worrying about conflict resolution or networking code. Powered by the Realm Mobile Database on the client-side and MongoDB Atlas on the backend, Realm is optimized for offline use and scales with you. Building a first-rate app has never been easier. Application Development Services With Realm app development services, your team can spend less time integrating backend data for your web apps, and more time building the innovative features that push your business initiatives forward. Services include: GraphQL Functions Triggers Data access controls User authentication Use these products from Google to accelerate the development and deployment of backend services: Google Kubernetes Engine (GKE) Google Cloud Functions (FaaS) Google App Engine (PaaS) Realm and MongoDB Atlas with Google Cloud and Android As Realm is a MongoDB product offered through Atlas, and Atlas is used by Realm to sync data between the database and clients, Google Cloud and Atlas abilities are key to the Realm user experience. Figure 1: Screenshot of Realm offered through MongoDB Cloud UI MongoDB Atlas and Google Cloud MongoDB Atlas delivers a fully managed service on Google Cloud’s globally scalable and reliable infrastructure. Atlas allows users to manage their MongoDB databases easily through the UI or an API call. It’s simple to migrate to, and offers sophisticated features such as Global Clusters that offer low-latency read and write access anywhere across the globe. 3 Key Abilities with MongoDB Atlas and Google Cloud Geographic Presence All Google Cloud regions have at least 3 availability zones, providing higher availability, resiliency and geographic availability. Other public clouds do not have the same reliability guarantees. Network Offering — Cost and Customer Benefits Global VPC - global resources that reduce complexity in networking implementation Performance - premium tier leverages performance of the Google Cloud network improving application performance and latency across tiers Price - better pricing ratio for network egress costs Native Integrations Security -- Atlas offers native integrations to Google Auth through Realm, support for Google Cloud KMS for additional encryption at rest or MongoDB Client-Side Field Level Encryption, and OAuth flow based console integration Billing -- pay as you go billing on Google Cloud Marketplace (Realm is purchased through Atlas credits similarly on Marketplace) Realm and Android With Realm, you can create mobile applications for Android devices. Realm supports all versions of the Android API after level 9 (Android 2.3 Gingerbread). Below is a sample reference architecture which shows how to leverage MongoDB Atlas with Google Cloud as an Operational Data Layer (ODL) / Operational Data Store (ODS) and build mobile applications using MongoDB Mobile and Realm Sync. Figure 2: Reference Architecture for ODL on MongoDB Atlas and Realm with Google Cloud Realm Customer Story — A Leading New York Healthcare Payer MongoDB has partnered with Exafluence to deliver a COVID employee self-assessment health checker app for a leading healthcare payer in New York since the onset of the pandemic, they’ve needed to quickly adapt to new operational standards, as the situation with COVID evolves. MongoDB Atlas, Realm, Google Cloud, and Exafluence have all been a key part of allowing their onsite operations to continue. The CDC and New York State require organizations to keep track of which of their employees reporting to a physical office for work. As a result, the organization must monitor their New York based employees who still come onsite in order to support their members. They needed an app that would capture their employees’ health, and ask a series of questions to determine if the associate was able to enter the facility. Exafluence -- a MongoDB Global Strategic Partner working with the healthcare payer’s HR team and business team -- was able to deliver a complete solution in only three weeks from start to go-live. This rapid deployment was made possible using MongoDB Atlas, Realm, and Google Cloud. The completed app includes: support for mobile devices a web Portal to aggregate information use of QR Scans to confirm access on iPads deployed in facility entrances integration with Active Directory and alerts to the funds email system This rapid deployment was made possible using MongoDB Atlas and Realm. The organization and Exafluence chose Realm because it’s application development services make it easy to work with data across both web and mobile applications. Realm works with React js, provides offline sync and is Atlas cloud ready. MongoDB Atlas and Realm also make it easy to rapidly develop new features when the next stage of the pandemic changes app requirements. Exafluence will be able to quickly add app features tied to vaccination, like the ability for employees to disclose and share immunization certification via MongoDB’s FHIR API. Prior to the Covid App, this healthcare payer chose to use Atlas on Google Cloud because the fully managed, global DBaaS accelerates development and allows them to manage both structured and unstructured data. They also needed a solution for analytics involving geocoding, machine learning, and dashboarding. With Atlas and Google Cloud, their teams get agility while with elastic scaling and provision on-demand resources. Additional differentiators that drove the organization to select Google Cloud include: Maps API Air flow for scheduling Cloud identity Kubernetes deployment and seamless integration with MongoDB and Realm for mobile development Scalable VM environments Meeting CISO requirements They were able to automate and offload operational tasks while taking advantage of built-in security best practices, and this in turn reduced regulatory risk. With Atlas and Google Cloud, their teams can also elastically scale and provision on-demand resources to build more microservices, in-line with their agile development requirements. Click here to learn more about MongoDB Realm
Built with MongoDB: Spectro Cloud
Recently named one of the hottest Kubernetes startups , Spectro Cloud has been making waves across the tech ecosystem. An enterprise cloud-native infrastructure founded by three startup veterans, Spectro Cloud makes Kubernetes manageable at scale for enterprises that need manageability and flexibility. Spectro Cloud’s cluster profiles automate cluster deployment and maintenance across the enterprise and help operations prioritize the needs of the applications teams and simplify infrastructure administration. The company has raised $7.5 million in seed funding and has 36 team members. In this edition of #BuiltWithMongoDB, we talk to CTO/Co-founder Saad Malik and Vice President of Product Tina Nolte about Spectro Cloud’s deeply technical team and why they #BuiltWithMongoDB. Siya Raj Purohit: What makes you want to work at Spectro Cloud? Tina Nolte: Most of the team comes from Cisco, where the founders previously worked, so we already had good rapport and were truly friends. We believe that culture is something you build from Day 1, and once it exists, it’s hard to change. For that reason, we have a strict no-jerks policy. How that plays out is that we provide a lot of autonomy to the team and help support goals that individuals have. For example, we encourage everyone on the team to write blog content about things they are interested in to share their knowledge and build their personal brands. It’s something that our engineering managers even nudge junior engineers about: “So you haven’t shared any wisdom with the world recently — why don’t you write a post?” If you—as a developer—experience some kind of issue, or it took you time to understand something, it’s likely that someone else on the planet has experienced that issue too. So we encourage our engineers to help them out, and it’s good for our engineers to have an external presence, too. See Spectro Cloud’s post: Kustomize your way to MongoDB ReplicaSet Finally, we talk about Spectro Cloud as a family. We’re pretty confident that other people have our backs whether it’s personally or professionally, and that kind of connectivity is pretty special. SRP: How did you decide to start using MongoDB? Saad Malik: Our application is not very data heavy in terms of transactions or relations; it’s very document based. Although we are running a SaaS platform, we didn’t want to be in the business of doing backups, managing policy, and storing configurations. We wanted to use a platform that managed these things for us. So we were looking at Amazon’s DocumentDB or MongoDB Atlas. We realized we would have to use an on-premises version of our platform, so obviously if we were to be running an on-premises version of MongoDB, it would make sense to use Atlas. Our team also had experience with MongoDB so it was a clear choice. And it’s been fantastic — we have been very happy with the performance, and so far, it’s been scaling very well for us. SRP: What has it been like to scale with MongoDB? SM: It’s been fantastic — we haven’t had any outages with Atlas. We obviously have our notifications configured so if there are any outages or things going wrong with the MongoDB clusters, we can catch when one of our clusters is misbehaving. That visibility and getting the monitoring upfront is very helpful to us, because we’re able to figure out which of our application issues is causing the problem. When we were getting started, we had a technical advisor from MongoDB provide us with a one-day seminar on best practices for utilizing the platform and how to optimize queries. From then on, the online documentation has been sufficient for us to problem solve and scale. SRP: What does the database infrastructure look like today? SM: On the database side, we have three different environments: dev integration, stage, and production. All three of them run an Atlas version from a database that is completely separate. The stack that sits on top of it is Kubernetes application, all using Golang, DB drivers for MongoDB, and accessing the application on there. SRP: What advice do you have for developers who aspire to someday become CTO? SM: The number one thing I look for is someone who is very curious. When I was an early-career engineer, my mentors would tell me to always be very curious and focused in terms of what you’re doing. Understand how things are working, not just at the library level, but keep on digging down until you understand not just how, but why something works a certain way. If you understand the nuances, you’ll be able to identify true game-changing opportunities. Looking to build something cool? Get started with the MongoDB for Startups program.