Skip to main content

Show HN: M3O – Universal Public API Interface https://ift.tt/hgDRI6H

Show HN: M3O – Universal Public API Interface Hey all, I'm Asim Aslam, the founder of M3O, a curated catalog of APIs that provides simple abstractions for the most common API use cases. The idea is to create a single place to explore, discover and consume public APIs as higher level building blocks. Most of the time I don’t use all the features of an API and I assume most devs don't either, so picking and choosing the common patterns, abstracting it away and surfacing a new building block is useful. For example, Twilio has a lot of APIs but I only care about SMS. Even then I just want a quick way to send it. So stripping it all away results in something that's one endpoint and 3 fields (from, to and message). Another example is something like email. There are services like sendgrid that provide a really feature rich experience for email but I’m just looking for something simple that will let me send plain text or html. There are a number of API marketplaces out there, but we’re doing something different—our goal is to improve productivity. For example, RapidAPI has thousands of APIs, but there’s a lot of duplication. It’s overwhelming for developers. Choice is the enemy of productivity. AWS, on the other hand, focused on a curated catalog of services where each focuses on a specific problem. We feel the same: from an API perspective you only need one of each building block. You only need one SMS, Email or Geocoding service. My obsession with this problem goes back to working as an SRE at Google in 2011, seeing how the internal platform and APIs were being used by teams. I then worked at a ride hailing startup called Hailo where we got to build something similar, and experience the velocity of development in shipping products on top of simple, easily discovered APIs. I spent the next few years bootstrapping an open source project called Micro, trying to get people to standardize their API development to reach this goal. Ultimately it took raising funding to take a real shot at it. After seeing the productivity Google unlocked and what Hailo could have done with their platform, it was clear it could and should be a product: a single way to consume APIs with one platform, one account and one framework. Our goal is to build an API catalog that can act as the building blocks for most use cases, and then double down on services that have a lot of demand so we can improve the features and reliability. In the wild, every API looks different, the docs are different, you have to figure out if there's client libraries or not. We unify all that, so everything looks and feels the same. All our docs are generated based on OpenAPI specs, and we code generate examples/client libraries for JS, Go, Dart and the CLI. It means you only ever need one client to access all these APIs. Unifying API development and consumption requires a lot of resources to do at scale, hence its only happening inside fast growing startups and large tech cos. There are a lot of barriers to entry. Getting started isn't easy. Our approach has been to first nail API development for ourselves and then focus on API consumption by end users— ultimately we want to let anyone offer APIs on our platform. That requires enough large scale distribution and inbound traffic to make an attractive proposition to developers. We've spent a year building the product with a lot of feedback on what worked and what didn't. We’ve signed up 8000 people, served 5M API requests and have 60+ APIs on the platform. On billing: we're still figuring it out and would like feedback. It started as a free product, then moved into per request pricing. Unfortunately that's hard to scale without a lot of volume and it felt like people were more used to subscriptions for SaaS products so that's the route we've gone. Anyway that's us, hope you like the idea and try it out: https://m3o.com . Cheers Asim https://m3o.com?show=hn April 25, 2022 at 04:09PM

Comments

Popular posts from this blog

Women Pioneers at Muni: Adeline Svendsen and Muni’s First Newsletter

Women Pioneers at Muni: Adeline Svendsen and Muni’s First Newsletter By Jeremy Menzies To close out Women’s History Month, here’s a look back at one woman whose work to bring Muni staff together in the late 1940s created a legacy that lives on to this day. Adeline “Addy” Svendsen was founding editor of Muni’s first internal newsletter, “ Trolley Topics .” Adeline Svendsen sits at her desk in the Geneva Carhouse office building in this 1949 shot. Trolley Topics was a new venture when it started in February 1946. As Svendsen wrote in the first issue it was created, “to bring a little fun, a little news, and a lot of good will to all our fellow employees in the Railway.” Just two years prior in 1944, Muni merged with the Market Street Railway Company, expanding the small municipal operation into the largest transit provider in the city with hundreds of employees, vehicles of every shape and size, and dozens of facilities scattered across town. The newsletter was meant to help unite ...

Show HN: StreetComplete, an OpenStreetMap Editor for Humans https://ift.tt/2J8IL02

Show HN: StreetComplete, an OpenStreetMap Editor for Humans StreetComplete is an OpenStreetMap[0] editor directed at people who want to contribute and want to do this using their smartphone, without learning how to edit things[1]. It is available as an Android application. It is intended to be used as one walks, with quests appearing as markers on the map. Selecting a marker allows one to answer a simple question. The answer will be added to the OpenStreetMap database, with app handling selecting objects for editing, transforming answer into OSM tags and making edits. OpenStreetMap account is needed to apply edits, but it is possible to start without it, make some edits and login/register later. Note: I am not the main author, but I am one of the active contributors. Github page is at https://ift.tt/2g8lasH and https://ift.tt/3nR9PzS shows what was recently released. [0]OpenStreetMap is a Wikipedia of maps, available on the open licence. This dataset is already used for many interestin...

Show HN: Launch VM workloads securely and instantaneously, without VMs https://ift.tt/2QwJ1Kd

Show HN: Launch VM workloads securely and instantaneously, without VMs Hello HN! We've been working on a new hypervisor https://kwarantine.xyz that can run strongly isolated containers. This is still a WIP, but we wanted to give the community an idea about our approach, its benefits, and various use cases it unlocks. Today, VMs are used to host containers, and make up for the lack of strong security as well as kernel isolation in containers. This work adds this missing security piece in containers. We plan on launching a free private beta soon. Meanwhile, we'd deeply appreciate any feedback, and happy to answer any questions here or on our slack channel. Thanks! April 29, 2021 at 07:50AM