Help me clarify some questions for our developer

Hi, we’re currently discussing using meteor vs firebase vs APIs. I’m a frontend designer but I don’t consider myself a super proficient developer, so here it goes: Some of my developer’s concerns vs using meteor are:

1. How do we both work on the same app?
Imo that’s simply handled by dev branches, then merging which then deploys to staging? Question is: How do we set up individual dev branches easily?

2. How to expand beyond web?
His concern is building an android app. His opinion is meteor’s frontend and backend are too tightly coupled and the logic should be on the backend (i. e. checking if a user is active), so how do we separate the logic of the database from the view layer properly? E. g. let’s say we want to grab a user profile, how do we make sure that web and android retrieve the same data. I guess his concerns are about mongo and the meteor.find(). It’s not standardized basically, meaning on android and web we could do different queries.

3. How feasible is it having many concurrent users with meteor?
He thinks it’s bad for performance because every users directly accesses the database whereas with an API approach for example you first call the API and the API manages how to access the database and access the load.

4. How secure are meteor apps?
He also thinks it’s very dangerous exposing the entire database to the user

Correct, you manage that via independent git workflow - nothing special to meteor. Take a look at “git flow” as a really good approach. First of all you do not need a branch for each developer, because you should work with a central repo like github. So every developer has its own copy of source and workspace until running push/pull. You should create “feature” branches for parts of your app you want to append without affecting the main app.

In using meteor, no one stops you from creating an api. So you may create yourself a REST api (restivus) and communicate to a number of “frontends”. Also you may use DDP as technology and connect through android apps or whatever. Last but not least, depending on your case, you may also create the android and ios app directly with you meteor development.

How you access your database and what kind of magic things you want to implement caching is free to your developers. There is no direct access to database per default, it is publish and subscribe. So the idea of meteor is to have some data available on your client while running the app. The database is more like a backend storage. In addition you may create server methods and api to handle data more efficient if you need that.

The database is not exposed to the client - this is only done when not removing autopublish and insecure. On production apps you have a number of options and packages to handle security and access to your backend.

All in all your developers concerns can all be handled seriously by meteor development. The more question is, if they maybe don’t like that stack and looking for some arguments to be negative.

If you start with meteor development, you (team) should carefully check again pub/subscribe and server methods to use meteor “the right way”.

Good luck

1 Like

Hi Tom, thanks for the reply. For the dev branches I was rather referring for an easy way to deploy dev branches. At my current startup we seem to have something set up to easily just deploy a branch based on the branch name, so something like for example.

The other concerns yea … I’m aware of most of them it’s just I can’t articulate the technical details properly unfortunately :confused: So I’m not good enough at showing counter arguments against his concerns.

Also to clarify: You wrote “there is now direct access to database per default” but I believe “no”, right? Meaning, by default nobody has access to the database. I think he’s also talking more high-level about access to the database. Meaning if we publish/subscribe to some collection the user has direct access to the database. I’m guessing this is not really true?

I’m already using publish/sub and server side meteors for inserts/updates/etc but to him it still feels too tightly coupled backend and frontend. Which I can’t really understand. On the frontend I don’t really care what will happen in the backend, I just call the methods defined in the backend and fetch data based on what the subscirption exposes to me.

Hi Andreas,

yes it should be “NO” - I corrected my text, thanks.


I am some type of “git enthusiastic” :slight_smile: so the “git flow” is really cool for deployments and developments. Just in a short as we use it:

  1. Master is just a dummy with the initial commit.
  2. Always work on the develop-1.x branch
  3. From there we merge to master-1.0
  4. Latest master-?.? gets always automatically deployed
  5. Hotfix are done by:
    1.1 Branch master-1.x (where error occurs) into hotfix-1.x-bad-issue
    1.2 Fix that issue on that hotfix branch
    1.3 Create new master-1.x.1
    1.4 Merge hotfix to new master-1.x.1
    1.5 Merge hotfix into current develop-1.x
  6. If you have special feature requests, create branch feature-1.x-my-super-idea
    1.1 When finished the feature, just merge into develop-1.x

This is a complete and great documented typ of flow. All is possible only by git/hg where the tool allows to merge branches as often as liked but without re-merging already handled hashes.

I love git :heart_decoration:

The only possible access you have on front-end side (lets do it via console) is that you may read the published data from the minimongo. But at least that is exactly the data you have published and therefor allowed to access by the user. Otherwise your app won’t work. So yeah, the data a user is allowed to, can be accessed :wink:

But you CAN’T change the data on the client and store this in backend, when your application won’t like that. Even that I can change data by console on the minimongo, it is NOT save in backend if your security setup is right. The minimongo is more something like a local cache of data for speed, latency compensation and cache.

I can’t understand too.

For me there are three concerns at your developer(s):

  1. They don’t like the approach of meteor
  2. They don’t like node framework
  3. They are not well introduced in meteor

One of this or all may be true :slight_smile: