Turn off the client (and DDP)

Is there a way to turn off the Client portion of meteor in 1.8? There is no client code, but still going to localhost:3000 will bring up a blank page with scripts loaded.

I’d like to only use meteor server side if possible.

Also, since I’m using this Meteor server for a GraphQL server, is there a way to remove DDP as well?

Really I’m just using this new Meteor server as a build/bundle tool, for Meteor Accounts integration, and as a GraphQL server to connect to an existing Meteor Mongo database.

For as far as I know, there is no real way ‘yet’ to run Meteor without its clientside. You can however remove quite some packages including meteor-base. In my test, the file looks like this:

# Meteor packages used by this project, one per line.
# Check this file (and the other files in this directory) into your repository.
#
# 'meteor add' and 'meteor remove' will edit this file for you,
# but you can also edit it by hand.

mongo@1.6.0
standard-minifier-css@1.5.2   # CSS minifier run for production mode
standard-minifier-js@2.4.0    # JS minifier run for production mode
es5-shim@4.8.0                # ECMAScript 5 compatibility for older browsers
shell-server@0.4.0            # Server-side component of the `meteor shell` command

ecmascript
webapp

If you don’t use mongo, you can remove that one too. Now for the clientside. This would be my work-around. Not ideal, but nothing exposed too:

In your server.js:

import { WebApp } from 'meteor/webapp';

WebApp.connectHandlers.use('/', (req, res) => {
  res.writeHead(404);
  res.end();
});

This would simply throw a 404 on every request and will not load any scripts to the client.

Maybe other people have the actual fix, but this is closer :stuck_out_tongue:

2 Likes

Thanks @cloudspider !

I didn’t know I could get rid of the meteor-base package… Ha, I already got trid of ‘meteor/webapp’ (as I use express) so I can’t really short-circit the request to 3000. :frowning:

The only real Meteor code I’m running is calls to the Accounts package (via ‘meteor/apollo’) and calls to the Meteor Mongo package (via ‘meteor/mongo’).

Also, this server is a apollo express server, and usually (usually meaning non-Meteor node applications) express servers are non-blocking, but the one I’m running in Meteor IS blocking, because server side Meteor runs on a Fiber that’s sync correct?

I suppose I could get rid of Meteor/Mongo too… but what would be the point when I’d just have to install Mongodb to communicate the the mongo server.

import {MongoClient, ObjectId} from 'mongodb'

const MONGO_URL = 'mongodb://localhost:27017/blog'

const db = await MongoClient.connect(MONGO_URL)

const Posts = db.collection('posts')
const Comments = db.collection('comments')

I guess if I went that far, then I’d start looking for a way to integrate Meteor’s Account package into a regular Node.js express app! :smiley:

It only appears sync, but the event loop continues in the background and pauses the Fiber till the underlying async result is ready, at which point the function will resume.

No idea if Apollo requires WebApp, but removing WebApp sounds like the way to go?
For DDP, I’m pretty sure Accounts needs it, so that might not be removable in that case

Apollo works fine without webapp. It depends on what service you attach apollo to, in my case it’s express. So I have one service (apollo express) running on a port, and then port 3000 that pushes scripts to the client (even though I don’t have one). Would love to get rid of the client part, but looks like that’s not an option.

Didn’t know that – looks like I’m going to keep it then :slight_smile: (or else manually pull out DDP from Accounts, but that’s too much trouble for now).

Still trying to process this one…

Sorry, that was a very jargon dense answer haha

Fibers are basically magic in that they allow you to write sync-style code, without blocking.

As an example, say you had to make an external API request as part of a client request. In Meteor, you can write it as though it happens synchronously:

WebApp.connectHandlers.use('/example', function (req, res, next) {
  const foo = req.body.foo;
  const result = HTTP.post('https://example-api.com/get_data', {data: { bar: foo } });
  return res.end(result);
});

Normally, a http request needs a callback to be async. Instead, with fibers, this individual function call is paused while waiting for the http request to return, but the application is not blocked.
Node will continue receiving and processing new requests from the same and/or other users.
When the remote API returns a result, the original function is resumed and finishes executing.

It’s basically async/await without the special syntax

2 Likes