Has anyone taken a look at or experimented with jsonfeed.org? Some relevant NPM packages include:
I’ve run into project after project where people want to use a REST API, where sticky-sessions become a bottleneck for scaling, and where multiple device builds are used (mobile, web, desktop, etc). A pattern we continue using over and over is to use DDP to subscribe a bunch of clients to a server publication (which is basically relaying the oplog), and then to complete the round-robin through a Meteor.method() call; often a ValidatedMethod.
It occurs to me that maybe JsonFeed is the architecture pattern we’re trying to implement, and it makes for a natural fit with JsonRoutes. All the benefits of DDP, but stateless and without the need of sticky sessions or an nginx proxy, compatible with OAuth, etc.
Besides the websocket optimizations, can anybody think of a reason why JsonFeed/JsonRoutes couldn’t be a functional replacement/upgrade to the DDP protocol? Could this be integrated with Apollo?
1 Like
I feel like I may be missing a trick here (not enough coffee in the world today), so forgive me if I’m off track.
We recently did something which I think is similar to what you’re talking about, using Restivus (which builds on JsonRoutes) and the JSend specification. The purpose was to connect an Express app to a Meteor app with some simple POST/GET functionality.
The dev experience was pretty nice. Biggest pain was getting the JSON format consistent on both ends. In other words, not bad.
Default authentication in Restivus is with accounts-password, but looking through the issues it seems it can be configured to use OAuth. (And I saw you were commenting in there, @awatson1978 , so I guess you’re aware of all this.) Anyway, the exact implementation isn’t so important. I more wanted to note that even right now if you want to use Meteor server-only and use something else client-side, you can get a pretty good experience.
In our case we were hooking two servers up, but if you could opt out of DDP and just use AJAX on the Meteor client side, it would look similar. Only thing is that would require what I imagine is a fair bit of work to de-couple. On the client, you’d either lose things like Meteor.user() or need to be able to plug in a middleware or something.
Anyway, it seems like this is similar to what you’re suggesting? I’d be all over it, and from the number of questions I see around about using Meteor for just client or server, I doubt I’d be the only one.