Similar projects and alternatives to m3o
Real World Micro Services
API first development platform (by micro)
Appwrite - The Open Source Firebase alternative introduces iOS support . Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!
The open source Firebase alternative. Follow to stay updated about our public Beta.
A starting point for building an iOS, Android, and Progressive Web App with Tailwind CSS, React w/ Next.js, Ionic Framework, and Capacitor
TypeScript execution and REPL for node.js
Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.
🐘 PHP Runtime for ▲ Vercel Serverless Functions (by vercel-community)
The React Framework
An extremely fast bundler for the web
Rust-based platform for the Web
A Go microservices framework
Generate Go client and server boilerplate from OpenAPI 3 specifications
Like Next.js / Nuxt but as do-one-thing-do-it-well Vite plugin.
A collective list of free APIs
Empowering everyone to build reliable and efficient software.
The zero configuration build tool for the web. 📦🚀
⚡️ Express inspired web framework written in Go
A standard library for microservices.
Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.
m3o reviews and mentions
Ask HN: Who wants to be hired? (January 2023)
22 projects | news.ycombinator.com | 2 Jan 2023
Email: [email protected]
Spent the last 10 years mostly working with microservices and Go based startups, although I would not recommend microservices to most companies. I can save you a few million dollars if you wonder why.
I'm most passionate about improving DevEx in companies. Things like writing custom ORMs for lesser known/supported databases (see eg. https://github.com/gocassa/gocassa). Mostly worked with startups from $2M-$500M funding range, with the occasional enterprise gig.
Used to run a chicken shop as a hobby project which made me careful of accepting management positions, haha, people are hard. I would love to be a product owner, I mostly designed the https://m3o.com/ product with the CEO recently and implemented the MVP of it. It's open source stuff, check it out https://github.com/m3o
Currently working for a US startup but my contract is ending soon.
Go Framework: No Framework?
It goes back to, what is a framework and what qualifies as a big framework here. I think classic rails isn't the fit, but something that's an extension of gRPC definitely works. What gets handcrafted is a lot of layers around gRPC or far more stuff around HTTP.
When I'm working on personal projects, frameworks don't make sense for me. When I'm trying to engineer something at scale e.g https://m3o.com then I need that standardisation at the platform layer, the framework layer, the API layer.
What if any is the relationship between https://m3o.com/ and https://micro.dev/ ?
Yup, I was the author of go-micro. It was very much a standalone Go framework aka common interfaces grouped together for distributed systems development. By using interfaces they effectively became pluggable abstractions for infrastructure. Unfortunately I don't think a Go library alone solves the problems I was trying to solve so it got merged into Micro which is platform that includes a CLI, API, Runtime, etc. It powers https://m3o.com
[API Request] - looking for Whatsapp status tracker API
2 projects | reddit.com/r/api | 22 Nov 2022
We can potentially do this on https://m3o.com. It doesn't exist yet but would make sense as the next service we offer. Further details would be useful e.g endpoints required.
OpenAPI Generator allows generation of API client libraries from OpenAPI Specs
11 projects | news.ycombinator.com | 15 Oct 2022
We ended up building this in-house like most mentioned. Speakeasy and Stainless are productizing it. Our goal was just to make it available for APIs we were offering to others (https://m3o.com).
Real World Micro Services
I value your points because they are the same concerns I would have being a CTO of a company. Ultimately vendors don't yet care enough about this problem to invest in it and I think ultimately that's a mistake because while we have standardisation at the Cloud infrastructure layer, we're missing everything above it. The cost of development to an organisation in these services is quite frankly astronomical. You've got hundreds of devs rewriting identical CRUD services or proxy shims to existing SaaS across the entire industry. That's millions in capex just being burned.
In relation to being a CTO of a small startup, yea OSS maintainer risk is tough. You want to use projects that are used by hundreds of companies and actively maintained. In my case, I am the primary maintainer and it's used for a cloud service called M3O - https://m3o.com. I think it will take a while before we're in a place to warrant more buy in but my hope is eventually it'll get there or at the very least people will come to use the APIs serviced by M3O.
On architecture, I mean you're quite literally talking about software "build vs buy" tradeoffs for the entirety of all software you ever write. In this case, do I integrate something else or write it myself. I think that comes down to the same assessment of whether you should offload to some other piece of software versus your own. When it comes to domain specific services this is always tough yet we see the adoption of the likes of Twilio for SMS, Sendgrid for Email and Stripe for Payments so I'd argue we're getting closer to blurring the lines now.
On cost, you can use the hosted offering - https://m3o.com - but at this point the reason I'm sharing the open source services is really because I think that adoption curve to a cloud service takes a lot longer especially with domain specific services. I would argue these services while on the surface appear a commodity, the development time and integration cost of using bespoke independent APIs or services has a much higher cost. Everyone internally ends up writing proxy/shims to SaaS products to try eliminate this risk for themselves. I just think we should standardise a lot of our business logic service consumption.
lol, really don't want to be in the same sentence as Urbit so please no.
Everything is defined as protobuf interfaces, which is a standard used by Google and everyone else now that gRPC is so dominant. So the idea is, define the API in protobuf, code generate and implement the handlers for it. The service can be called by other services on the platform using that code generation and then an API Gateway, which Micro provides can be used to call services externally using the same format but using HTTP/JSON.
To take that even further, M3O (m3o.com) codifies protobuf to openapi specs and then generates client libraries on top. You can see some of that in https://github.com/m3o/m3o.
React projects ideas (no backend)
2 projects | reddit.com/r/react | 23 Sep 2022
Check m3o.com I’m building an app using their apis
A note from our sponsor - Sonar
www.sonarsource.com | 24 Mar 2023
m3o/m3o is an open source project licensed under Apache License 2.0 which is an OSI approved license.