re: Who's going to write us a post on alternatives to mongoose ? VIEW POST

re: @mfahlandt , I totally agree with @johannestegner . Majority of developers in JavaScript aren't "developers in JavaScript"; they are developer in a...

For Example you have a mixed type where you still want to query
account_id: {type: String},
content: Schema.Types.Mixed,
textfields: Schema.Types.Mixed,
created_at: {type: Date, default: Date.now()},
updated_at: {type: Date, default: Date.now()},
deleted: {type: Boolean, default: false},
new_assets: [Schema.Types.Mixed],
tags: [String]

I want to enforce that fields are set because you have multiple teams working on this input and still you have the possebility for all the query options that you do not have in postgres subschema.

I never stated that Mongo is the one and only solution for everything. I stated that it is often overkill to use each specific database type for the perfect fitting moment. Why? Because you often don't have the developers that can work with both options, or don't want to work with one or annother option. Or you have to comply with company politics.
Sorry but the Real world is not all the newest and most advanced stuff and most companies simply don't have the ressources or the understanding to use each type for each option. Even if you have the people maybe it is just not worth implementing it. These are business and political decission that define things in the real world. If you work in fancy startups or on greenfields you mostly can do what you want. But this stops at the point you have multiple teams and legacy system that need to work.
You are all describing the perfect world and we are not in the perfect world.

Scalability is harder in mysql when you dont want to pay the higher prices for RDS (and they are not worth it, in no case), you even use RDS and loose all of the finetuning options for your database. I mean come on you can't even export users with a dump in RDS PostgreSQL.
I prefer having all inside of Kubernertes Clusters and there scalability is easier with mongo than any RDS System. Why? Because I'm not vendor looked and i laugh at everyone when AWS double it's prices.

Also your are basically in a VPC without any conenction to the outside.

That was a mere remark with no intent to be hostile; regardless.

Again, you are defining a schema, a structure. Something which is probably better for RDBMS. Your problem is related to the way the data is retrieved and not the way the data is stored, indexed and analyzed.

...you don't often have developers...

That's the fault of your recruitment and on-boarding team. MySQL and Mongoose are the two most popular database systems and any good developer would have no problem in picking it up and using it. His/her mistakes can later be fixed in a CR session. Even if they don't know how to use it, one of the developer can mentor them: that's the entire point about writing software; learning new things and making yourself better.

If you are still stuck in that loop of using technologies like they are instead of going with something which has been battle tested then I feel sorry for your systems.

...or you have to comply with company politics...

Pardon me, but wherever I have worked, we never had company politics in the Engineering team. We discussed, experimented, failed, re-tried. (Oh, before you comment that this is a startup, no.)

...not worth implementing...

That's a different scenario in itself.

After all of your talks related to scaling, a quote comes to mind: over-engineering is just as bad as under-engineering. That doesn't, however, serve as an excuse to use Mongo and define relations through virtuals or ref because you "want it to feel like a RDBMS."

I am not defining or describing a "perfect world." I am defining a continuously moving and advancing world. While I agree that the newest and the shiniest technology shouldn't be a backbone of an entire infrastructure, battle-tested and proven tech should be.

If you work at a startup and think that "this is a greenfield and I can experiment with whatever I want", you aren't doing it correctly.

Scalability is harder...

No, it's not if you know what you're doing. The direct refuting argument to what you said is that enterprises (with "politics", as you so portray), have a dedicated DevOps team which takes care of all of this so the issue doesn't even arise in the first place.

...pay higher prices...

What do you reckon RDS costs? It's a managed instance giving you the free time to write code: your job.

...fine-tuning options...

What? Which RDS instance did you use?

...export users...

You can. You need to create a port-to-port SSH tunnel and access the RDS instance like it's on your own network. You can do everything in that instance like you would in your own database instance.

...Kubernetes cluster...

Isn't that a little more complicated? Which goes directly against your "remote teams" and "don't know how to use it", etc. argument?

...Mongo than any RDS system...

Umm. I am at a loss here. You want to scale but are unwilling to use AWS for it and do all of this manually at the expense of your time and effort. What.

...AWS doubles its prices...

Elasticity of demand and supply. It doesn't double its prices; the changes, if you are region-specific, are negligible. Usually 10-15 USD/year. That that too when you are on-demand.

...you're basically in a VPC...

There was no need for hostile remarks. But, I am glad that the VPC doesn't have any connection to the outside. Maybe I am in the subnet for HIPAA/PCI compliant instances. Good thing! Thanks! :D

I think we reached a point in the discussion, that is pointless to continue.


You are basically saying: kick all people out of companies, no matter how log they have worked with the company, because they are not able/willing to learn another database. Not the most social part.

Also you seem to never have worked for companies that came from other sectors to web/IT where the old politics also apply to new sectors. And these companies may not have a dedicated DevOps team.

First: Coding is not my Job. Completly relying on a hosted service by one vendor is stupidly dangerous. There are reasons why projects like Istio are comming up to have multicloud solutions. And sorry to say this there the way to go is Kubernetes. I would never use any dedicated vendor product, just because you do not know what will happen.

Maybe it is a different use case in germany, but we are stuck with legacy code, legacy system and lots of lots compliences that even state the servers have to be on german soil for certain things.
But i know this as well from other western europe countries and companies in the us.

We surely have reached that point.

I am not saying that. And I never said that "kick them if they are not willing to learn another database." I am saying that it's a sign of a good developer to learn something new and apply it. If you think that you are going to have one skill set and apply it everywhere without learning anything new, then... I am not sure what to say. Now, before you misconstrue that and think that you need to be on your toes and learn everything to be good.

Also you seem to have never...

I have worked with a lot of companies in a lot of different sectors; food, education, marketing, sales, ops, logistics and I am yet to see this level of dystopia you mention. Maybe it's because the new heads of these companies are doing their jobs right and keeping things where they belong.

Completely replying on a hosted...

Umm. What? You do realize that Amazon.com and a lot of other applications you use on a daily basis (Netflix, for example) are deployed almost exclusively on AWS.

Your argument of "the way to go is..." is a classic example of how when someone is comfortable with one technology, they use that regardless of anything happening for every single project.

As far as Istio is concerned: there is a reason why AWS has faired for such a long time.

I don't understand why your entire argument chain shifted from database technologies to a cloud provider.

Ok let's get back to why it might be useful do define models:

The database needs protections from it's foremost enemy: the developer
If you have some basic layered structure of data you force the developer to think instead of just vomiting data in your database.
If you have at least partial structured data you also have a bullshit filter of what comes into a database.
If you have structured data you can be shure that for example an idex of a field exists. There is a reason why you can set indexes in mongo.

Schema and Data Modeling is part of MongoDB, heck it is even in the documentation: docs.mongodb.com/manual/core/data-...

You could now come again with the argument why not use PG, simple less options querying the unstructured Data within you possible model.
A Mongo Cluster is also working way more reliant as soon as it comes to cross region scale, even if you use a managed service like RDS

You brought up the point it is easier with using DaaS and then brought up some strange views using mono cloud SaaS.
Why not use single Vendor cloud?

How nice that you choose Netflix, roughly one year ago AWS East Us crashed and was down, half in the US Netflix, Github and some other service have not been available for over 6 hours.
Gues what, Netflix moved to Multicloud and uses Google Cloud as well, because of this.

Also cloud platforms, regardless of form factor or delivery method, are not all interoperable with each other or with legacy systems. There is often an assumption that all will play and talk nicely together and push and pull data easily; this is not the case. Therefore, the ability to mix and choose between offerings in a multi-cloud environment

You cannot easily move your infrastructure to annother provider. The question might be why would i? You do not know exactly what is on layer below, there might come changes that you did not antacipate. Or simply a matter of cost.

Additional you have advantages like lower lateny, higher security.

Most of the bigger companies, are or currently moving to multicloud enviroment.

I drop out of this discussion now, because in my opinion the view of this discussion is only in seeking to find flaws.

The database needs protections from it's foremost enemy: the developer
If you have some basic layered structure of data you force the developer to think instead of just vomiting data in your database.
If you have at least partial structured data you also have a bullshit filter of what comes into a database.


This is actually an argument I can agree with. Personally I do data validation on my database abstraction layer, but using mongoose for that is also a good option.

code of conduct - report abuse