Why I Use Meteor.js in 2022

deployment
1

TL;DR

I choose Meteor as the starting point for all my applications because of three reasons:

  1. Shortest time to get “up and running” and start working on value creation
  2. Battle-tested and long support history
  3. Ability to easily scale applications through MicroServices when (or if) an application becomes successful
14 Likes
2

Thanks for sharing. Can someone speak to the benefits or downsides of the /api structure specifically separating /services and how it might work in practice? I think I understand but hadn’t seen this shared before and am wondering why it wouldn’t be the default recommended structure in the Meteor tutorials.

image
image1125×2095 149 KB

3

Interesting and thanks for sharing.

So your micro-services would then have to run their own authentication etc.? I.e. - It would have to be available just to your Meteor server and nobody else. Is that right? How do you go about doing that?

4

Can someone speak to the benefits or downsides of the /api structure specifically separating /services and how it might work in practice?

I tried to explain the benefits in my blog post, but I don’t think I explained it very well.

By moving the business logic of the application to the /services folder you are able to easily convert your monolithic application to a microservices application by service as your application grows.

So your micro-services would then have to run their own authentication etc.? I.e. - It would have to be available just to your Meteor server and nobody else. Is that right? How do you go about doing that?

That is correct. My recommendation would be to have your microservices in a private VPC that is only accessible from you Meteor cloud-instances, and always use some type of authentication for your microservices.

Here is an example of VPC architecture utilizing NAT gateways to have your Meteor instances publicly accessible, and your microservice instances privately accessible.

3 Likes
5

I’m not super familiar with microservices so forgive my potentially dumb questions. :slight_smile: I’m wondering why you wouldn’t want to have {CollectionService}.js in the same folder as /{Collection Name}. Is it to ease portability when creating a new microservice or is there some other motivation?

If I’m understanding correctly, your Methods would basically just be calling another function in CollectionService.js so do they look something like this? Or do they have more responsibilities?

import { exampleFunction } from '../services/CollectionService.js';

Meteor.methods({
'methodName': exampleFunction
});
6

So in this scenario each microservice is still a full Meteor application, is that right? And you’re just routing specific methods to specific instances? Meteor itself has quite a bit of overhead (which is justified for all of the nice things that it offers IMO) but if I were making the effort to split a method out into its own microservice for performance reasons I’d probably just move it into a basic node lambda to make it much cheaper and faster than a second full Meteor app. It’d be interesting to see a cost + performance comparison of splitting some intensive task into its own Meteor microservice vs just a lambda microservice.

7

That is exactly how it is structured for my projects.

There is not a particular reason for creating a separate /services folder under the root /api folder other than preference.

2 Likes
8

No, in my project architecture I will convert the specified service to a lambda/serverless microservice with basic Node.js or Golang.

2 Likes