Starting a new project on eCommerce platform, and confused on which JS stack to use? Between MeteorJs and AWS Amplify, which one should we choose and why?

help
1

Hallo Friends, I am a hardcore fan of Meteor, but now in my company we are faced with a dilemma. We are working on a client project to build an eCommerce platform similar to InstaCart. Client is open on the Technology stack. The Dev team is split between MeteorJS and AWS Amplify.

Requirements of client:

  • Future proof technology stack
  • Easy and continuous deployments
  • Easy and minum DevOps
  • Test driven development
  • Cost and ease of maintainace
  • Infinitely Scalable

I see lot of similarities between Meteor and AWS amplify, below I list some of them.

  • Both have real-time data sync - Meteor DDP, AWS Appsync
  • Both come with strong inbuilt accounts management package
  • Meteor has methods, AWS has Lambda
  • Both built on node

For me, AWS Amplify in many ways is a clone of Meteor.

Below are the pros and cons of using Meteor over AWS Amplify

Meteor

Pros:

  • Ease of local development
  • Familiarity with Meteor environment - almost nil learning curve
  • Integration with Cardova for creating app - write once, run everywhere

Cons:

  • DevOps - huge headache
  • Hosting Headaches
  • Scalabilty
  • With Meteor core team focusing on Apollo and GraphQL, we fear that Meteor may be abundant
  • Future readiness

AWS Amplify

Pros

  • Fully integrated Platform
  • Minimum DevOps
  • Future Proof (Hopefully as coming from Amazon)
  • Lambda is serverless
  • infinitely Scalable (Hopefully)
  • Build apps with react native - lean once and deploy everywhere (ehh almost … :wink: )

Cons

  • Local Development
  • Significant learning curve for the team
  • Hosting and hidden charges
  • Single vendor trap

Could this community be so kind to help me solve the dilemma? Thank you very much.

2 Likes
2

Nice list - it looks like you guys are very diligent.

Now, obviously I’m biased towards Meteor, with portability being one of the reasons (here’s a related post). But not depending on a vendor is a very big plus on the side of future proofing.

Besides, I would say the DevOps part for Meteor is actually minimal. It’s a Node app that needs sticky sessions - it’s that simple. Any sysadmin worth their salt should be able to set up a deployment routine for you in hours. If you don’t want Galaxy or don’t have the time yourself that is.

1 Like
3

Regarding the sticky sessions, will meteor work even if we have 1 Million concurrent users, and if yes could we estimate the kind of resources required? Will that increase the hosting costs exponentially?

1 Like
4

I don’t see why not. But the best answer to that is: test your assumptions, a forum thread won’t give you the numbers.

If I were in your position, I’d build two prototypes with some collections that I expect would be the heaviest. One for Amplify and one as a Meteor app, perhaps also deployed on AWS, to save time. Both should be in the same region.

(If you want pub/sub, you might want to use redis-oplog, though if you expect huge traffic volumes pub/sub might be better limited to something light, like user notifications. Again, test.)

The number of users can be difficult to foresee, but the volume of content not. So strategise around caching; use a good accelerator. I could see something like Redis easily serving your million users and more. A CDN for static assets comes without saying; these ones are more of a pain in the back than one expects.

Finally, use a good traffic simulator. I prefer jMeter, but you might have other strategies. If you lack the time, you can maybe employ the services of something like Blazemeter (disclaimer: only know them via Google, but they use jMeter).

Then sit back and look at how your prototypes behave with different batches of fake connections: 1000 / 10 000 / 100 000. And from that you can see if it’s a linear or exponential resource consumption.

I personally expect Meteor to behave very well under this kind of load, provided you do proper caching. You will need to cache either way.

If the project is expected to serve the kind of load you’re mentioning, then it must also be of high value. So I think a week or so spent prototyping and testing is a drop in the bucket compared to the the huge cost of a potential mistake.

3 Likes
5

Forgot the sticky sessions part: for something like Tengine (customised Nginx), serving a million connections is small meal.

6

Yes, that would be the way to go. Although 1 Million was just a hypothetical number, but you get what I mean. Regarding building the prototypes, we don’t have lot of room considering our team size and workloads. Regarding Caching, isn’t meteor handling of caching at client comes inbuilt? And on AWS amplify if we use Apollo as GraphQL client we would also achieve the same result of caching on client.

7

Well, to be honest, I took it at face value. If you say “hypothetical one million”, then any answer would be just as good.

I did not say anything about caching on the client. I don’t believe such thing exists built into Meteor. Maybe not re-subscribing if parameters haven’t changed - that’s an altogether different matter.

You seriously need to know what your caching strategy is going to be. From what I gather, you sound like you haven’t even thought of it. It will come back to bite you in the soft parts, not much further down the line.

1 Like
8

Can you share some good resources on how to implement caching with meteor? With an npm package? Or between the app and the db?

9

Our caching solution is multi-tier and covers multiple services, so it’s pretty much homebrew.

A few good solutions come to mind. Redis could be very helpful, and you can already use drop-in solutions like redis-oplog, built specifically for Meteor. Or if you need faster access, use something like node-shared-cache, with refill from Mongo.

Either way, if you use methods, write a wrapper for collection.find, which pulls from Mongo if the cache is empty. You can also use an observer that updates the cache when a document is added/updated/removed.

You can use something like Varnish to cache HTTP requests (e.g. static assets).

The possibilities are almost endless, but the solution is always going to be pretty custom to what you build.

3 Likes
10

Do you know https://www.reactioncommerce.com ???

12

Yes, I know reactioncommerce, but we need something very specific and specialized solution here.

13

I understand, but I think you can learn with them about your questions.

14

Very interesting topic. I love meteor as well and have been using since v0.8. I have been tracking reaction commerce for many years but their lack of focus on speed made me decide on another direction.

Our situation is that we have five shops with different catalogue and price-set all being delivered from our Microsoft Dynamics ERP.

The ERP maintains pricing, inventory and the very basic meta data like sku, ean. We use Akeneo PIM for our localized content and metadata in general.

My chosen solution is the following.

I have build my own server-side rendered frontend in express/handlebars and mongodb that is somewhat performant. (400-800 ms.) Speed in all aspects have been the priority.

Then I have chosen to link to a checkout flow build in meteor on a url like checkout.shop.com

The result is a fully rendered page within 0.8 seconds and 100% Google PageSpeed in mobile and desktop on product pages. We are currently running woocommerce and switching to the new solution within this week. The new solution is available here https://dynamic.fysia.se and the checkout flow here https://checkout.fysia.se

2 Likes
15

Here’s an excellent post about handling a lot of traffic by using a clever caching strategy: State of Meteor?

1 Like