Author here. The biggest gap I hit after removing MCPs was APIs without CLIs.
GitHub has gh, AWS has aws, but most SaaS APIs have nothing. That's why I'm building CommandSpec. The tool takes any OpenAPI spec and generates a typed Go CLI. Every endpoint becomes a command, every parameter becomes a flag. The AI discovers operations via `--help` instead of preloading every possible tool definition.
Happy to answer questions about the setup or CommandSpec.
I suspect that we didn't get enough Ember responders, because I do think they have a reasonable sized community. 9k responses is likely not enough to draw a reasonable conclusion that it isn't popular. I wish we could have paired up npm downloads or some other stat besides some of this data...
Offline support is tricky because each app needs to implement what happens in the case of data conflict. Meteor already has the groundDB package that allows for offline support in local storage. I would imagine you could implement a read only option into local storage once they release reactive graphQL.
Well said! I actually think the community has done a ton of work on Electron and we will see the desktop option soon too.
This announcement is exciting on many levels and I think some of the unspoken bits will be interesting later too. I hear they are working directly with people at Facebook on this project.
I think when you look at the companies using React now, you start to understand why it is gaining ground quickly. Couple that with the fact that Facebook has dumped a lot of efforting into the tooling around it, it makes sense to me.
Not having to spend money on Blaze will make them more competitive as a hosting business. Frankly, when is the last time you saw a billion dollar unicorn hosting business? Or a hosting IPO?
I doubt we will see SQL support. We will likely see something with GraphQL instead.
> First, Rails is not my job. I don't want it to be my job. The best frameworks are in my opinion extracted, not envisioned. And the best way to extract is first to actually do.
You are slightly wrong in your history of Meteor. It was extract from an app they built. Unlike Basecamp or Facebook, the app died off and they focused on just building the framework. So while it was extracted, I think MDG has missed a lot of the learnings that something like Rails gets from core contributors that are building applications and the framework together.
MDG has actually talked about taking one week twice a year to build 'apps' with the framework, but that just hasn't been enough. I am glad they are finally working with Meteor itself to build Galaxy and supporting Galaxy customers as well, that really gets some skin back in the game.
Imo, this post is just a manifestation of the deeper issue around profitability and the fact that MDG will need to jettison some of it's development costs and pick up a much larger base of customers if they want to be profitable.
Which PaaS also builds it's own programming framework...
You can easily use things like Heroku and Modulus to host your site. I think perhaps you are misinformed about your options and should read up a bit more.
I use Digital Ocean with MUP and it works great with minimal efforts.
It is a neat feature. I also hear that it will persist changes from node-inspector web interface back to your code itself... I didn't mention in the article as I didn't have time to confirm it myself.
Yeah, I am thinking of adding a debugging section as a PR to the Meteor docs.
GitHub has gh, AWS has aws, but most SaaS APIs have nothing. That's why I'm building CommandSpec. The tool takes any OpenAPI spec and generates a typed Go CLI. Every endpoint becomes a command, every parameter becomes a flag. The AI discovers operations via `--help` instead of preloading every possible tool definition.
Happy to answer questions about the setup or CommandSpec.