From LAMP to Meteor, Stack Suggestions

deployment
1

Thanks for clicking! I’ll try to make this short, but I feel that to get appropriate help, I need to tell a bit of a story.

I own a used car dealership that’s entirely Internet based (no salesmen, all info, communication, and negotiation is online). I built the original platform (client and admin client) on a LAMP stack with a dedicated, managed server (Liquid Web).

Version 2 of the platform must be real time and fast. To that end, 6 months ago I started on a new (stand alone) inspection web app for my mechanics using React/Redux/Webpack/Node/Express. It works well, but I had to become an expert in everything, particularly Apache trying to patch it with WS tunnels, reverse proxies, upstart, PM2, you name it. And the app still long polls (socket.io). And that on top of every API requesting architecting the chain from component action to API request, optimistic update, undo, reducer, error handing, server validation, response, web socket, duplicate data rejection, etc. I can see where such verbosity works well in a team, but for a one man band like me, it’s torture.

Meteor looks perfect. A very opinionated full stack. The more I look, the more impressed I get. I’m more than happy to give up some readability and testability for “magic.”

To the question. I’m used to the traditional LAMP and having everything on a server with all of the advantages a server provides. The idea of a distributed app structure concerns me, but not being my own dev/productions ops outweighs my concerns.

My app needs file access (writing and storing files, pictures, and videos and some of those files may be very sensitive like a credit application), a database, SSL EV certificate (I’m handling sensitive files and financial information), and obviously Meteor deployment. Is their a preferred group of services? My ultimate goal is to create this app, test it on my dealership, and then license it and spin up multiple instances for dealer clients.

Galaxy looks appealing. I’m not sure who to use for the database. I can’t tell if S3 is everything for file access.

I need a push out of the server nest. Any thoughts are greatly appreciated.

2

Wow - you’ve been through all that WHILE running a used car dealership? You may be impressed with Meteor, but I’m impressed with your throughput! :slight_smile:

There are many answers to your questions, so I’ll just try to throw in a few (and hopefully others will add on).

Well … sort of. Meteor has started to open itself up more and has become less opinionated over the past little while. This can either be seen as a good or bad thing, depending on which side of the fence you sit on. By introducing support for view layers other than Blaze (like React, Angular, etc.), and by now allowing proper npm package integration (no longer just using Atmosphere), Meteor has become quite a bit more flexible. With that flexibility though comes choice, which to some might be a bit scarey …

The above being said, since you’ve mentioned you have React/Redux experience, you’ll likely want to look into using React with Meteor.

You can either store files in a database using something like GridFS, or leverage a third party file storage solution (like Amazon’s S3, Cloudinary, Uploadcare, etc.). Both options will work, so go with whichever one makes the most sense with your requirements. One thing to note - try to avoid storing files on a local filesystem (unless you’re doing this for caching purposes or some other temporary reason). Storing files locally makes horizontal scaling much, much harder.

What kind of database are you using currently - SQL based or something like MongoDB? Meteor has traditionally only supported MongoDB as the database. Some members of the community have created packages for integrating with other databases (like Postgres, MySQL, Oracle, etc.), but due to the way Meteor was designed, giving those databases full support is quite difficult (and time consuming). MDG (the company behind Meteor) has started a new project to help address this called Apollo. With Apollo you can leverage GraphQL to tie into any type of backend (database, web service, etc.) you want. You can use Apollo with Meteor, and it’s only getting better as each day passes.

So long database story short, if you want to go the traditional Meteor way, aim to use MongoDB as the database. If you’re looking to leverage other types of databases (and don’t mind being on the cutting edge a bit), look into leveraging Apollo.

No problem at all - deployed Meteor apps are just node apps, and node can work with EV certs.

If you want to keep things simple, go with MDG’s Galaxy hosting option. Galaxy gives you dead simple deployments and it’s very easy to scale. If you want to host things yourself, there are a tonne of options you can consider (just search through this forum for production deployment options).

I love compose.io, but some have had better luck with mLab. Both are great options for remote Mongo hosting and the pricing is quite reasonable (when compared against the cost of hosting/maintaining/managing Mongo yourself).

Yes it is. Amazon S3 is used by just about everyone in Internetland™ for file storage, so you’ll be hard pressed to find a better option. There are many ways you can integrate S3 with Meteor apps, but maybe start by taking a look at the official Amazon aws-sdk npm package. That being said, S3 isn’t necessarily the easiest file storage option to get up and running with. Many people on this forum prefer other solutions, so search through the archives for alternatives.

1 Like
3

That was a huge help! Thank you. Let me try to be brief in my reply.

Thanks, it’s been fun ride. I’m an electrical engineer turned IP attorney turned used car dealer. (Listen to that horn toot!) But I really love programming. My goal is to turn the current car dealership into the next Tower Records. We’ll see.

I painted with too broad a brush. Opinionated with respect to scaffolding a program. You don’t know how amazing automatic optimistic updates with undo is until you have to hand wring it. :slight_smile: When I saw a tutorial make user auth in 3 or so minutes, I was hooked. Plus Sessions that seem to act like my beloved PHP $_SESSION user global. You had me at global.

I looked at Cloudinary. I’m glad you brought it up – it makes me think I’m on the right path. My big concern with Cloudinary is the sheer volume of images from car dealerships. We take 100 or so 24megapixel dSLR pictures per vehicle. After making multiple sized images, that’s about 400 megabytes per vehicle. Cloudinary’s advanced plan is 120GB (190 vehicles) for $224/month. That’s not practical or scalable. Upload care and S3 have similar storage issues. I can’t find anyone that’s the Youtube for commercial pictures. Is there another way?

I’m excited to jump into Mongo. I have a ton of experience with Postgres and MySQL, but most of my data is best modeled as a nested object. Creating nests with SQL is a JOIN nightmare. The lack of a $lookup operator kept me with SQL (multiple sources of truth and updating all of those on update scared me into staying with SQL), but I’m excited to plunge into this maturing Mongo! (Also, React’s Immutability Helpers are modeled after Mongo syntax, so I have a head start).

GraphQL also looks amazing. Apollo looks like a simplified Relay, and given that MDG will integrate it with Meteor… I love it.

I don’t want to host things myself. I do that now and hate it. But I wanted to at least put the question to the community because some of the deployment sites (looking at you Heroku) start off seeming cheap but quickly explode into a cost mess. The Galaxy “container” system doesn’t make a ton of sense to a Meteor newbie.

I will keep searching based on your great suggestions.

My biggest stumbling block is scaling pictures. If you or anyone else have suggestions, that’d be a big help!

4

I have been looking at Google’s cloud storage for this requirement we have (classifieds site).

https://cloud.google.com/appengine/docs/php/googlestorage/images

In PHP it is done quite simply by adding options to the serving url. Have yet to look at this in detail for Meteor based applications. It is on my list of things to take a look at before plunging into Meteor.

$options = ['size' => 400, 'crop' => true];
$image_file = "gs://${my_bucket}/image.jpg";
$image_url = CloudStorageTools::getImageServingUrl($image_file, $options);
5

Thanks for the info. In my quick run through, it looks like you must host on Google App Engine to get access to cloud storage. Am I reading that right?

6

No, you can host anywhere and get your API keys from the cloud console.

We’re hosted on the Compute Engine (generic linux VMs)

More info - https://cloud.google.com/storage/docs/

7

I can think of numerous reasons why you might reject imgur.com. On the other hand, you might not have considered it.

https://market.mashape.com/imgur/imgur-9/pricing

Here’s an API documentation example.

8

Thanks for the info. I’ve taken a lot closer look, and it looks like a great scalable value. It’s orders of magnitude cheaper than Cloudinary (and offers regular file access, which I also need).

Which makes me think I’m missing something. Cloudinary offers on the fly scaling and image filters on a CDN. Are those the only reasons for the price difference or am I missing something important?

9

To follow up, I did a lot of research this morning and decided on AWS/S3 for static hosting (files and images). It seems like the big benefit of Cloudinary is the URL transforms. But S3 offers “Lambda Functions” (that name irks me). They’re basically self contained scripts that interface with S3.

My current dedicated server runs image processing scripts. I can simply save those scripts to AWS Lambda. Easy.

I still see the obvious benefit to Cloudinary’s URL transforms, but for someone with a ton of GBs, the cost difference is huge.