Continuing the discussion from Running multiple instances of Meteor with separate databases while being able to push updates to each:
Hey @aadams I already feel like I’ve hijacked that original thread so hopefully splitting this to another topic will help follow the two separate topics.
First, thank you very much for your kind words, I do sincerey hope this is helpful for you.
Ok so let’s first clear up the webapp/connect/express topic.
WebApp is a Meteor core package that deals with responding to http requests, this is what sends down the initial html/css/js bundles and sets up the initial connection for ddp to work.
Nodejs already has a
http api which has a
createServer method that sets up an http server for you. This is, in essence, all you need for a rest api because it enables you to listen for incoming http protocol requests and respond to them.
But the api is too raw for most people’s taste/needs. Most projects need a way to do a few chained operations on the incoming request, like parse the url, parse the body, set some headers, log a few things etc. Since most of these small operations are really common and shared across the whole set of endpoints, the term middleware was coined. So someone built a library that made it easy to define a shared api and connect these independent middleware functions, and called it
But there were another set of more specialized apps that needed more on top of this, web apps! They typically needed a built in router, a view engine, ability to serve static files and an _express_ive way to wire these all up so that same someone created
express, building on top of
Aside: There’s a whole complicated history around connect and express and currently, express is no longer dependent on connect, although the middleware api remains 100% compatible making most code from one reusable in the other, all the while the original developer of both has moved on to Koa and then stopped using node alltogether in favor of Go
Now I know that express is a lot more popular (github stars, npm downloads etc) but connect is also as well maintained and my personal preference lies with libraries that have smaller api surfaces whenever they’re sufficient. And I find connect to be 100% sufficient for most rest api projects. I use a router middleware to make working with routes easy and I’m covered.
You can of course use express, but to me it feels like buying a swiss army knife for its screw driver while there already is a screw driver lying around, which is
WebApp.connectHandlers() which is
connect in half-disguise!..
So, out of box, Meteor indeed “does offer a restful api” because it has no less to offer than what a barebones express app offers, a single route that matches
/ and responds to http requests!
Now, moving on to the ddp/rest/method/graphql discussion.
So the question is, what api(s) should one offer from a server side (possibly meteor) application?
To answer that question, you should look at the capabilities of the client apps that would connect to your server app.
Obviously, Graphql (possibly via Apollo) is an increasingly popular choice, while REST is kind of an hard to miss target for the forseable future and DDP (pub/sub and methods) is a very productive choice if you can get the clients to speak DDP.
If you’re already invested in a meteor application and simply would like to increase client coverage, you can use atmosphere packages like
simple:rest which both have the ability to expose your methods/publications as rest endpoints without much effort.
This could very well be a stop gap solution until you refactor your application to separate your “application logic” from your “api protocols/endpoints” such that you can reuse the application logic to create any one or more of the alternative api facades and be safe even when something new becomes the new groundbraking api protocol next year!
If you are starting from scratch, though, that’s another story which requires you to do some research and surveying to figure out your application ecosystem.
meteor create command.
Final note: As with all technology stack, languages etc, there will probably be one point where your scale or specific requirements will call for including other small or large pieces of tools to solve some specific aspect of your application domain. There’s no one size fits all but this one-size - meteor - is quite dependably versatile.