…this topic was closed by author…
Apollo won’t be ready this month. But maybe in 6 it will be able to handle many users!
1 Like
What??? Apollo won’t be ready this month??? But you guys even had an extra leap year day! Well, I guess that’s okay … as long as you promise to deliver April 1st … I’ll be watching Meteor news that day intently for an Apollo launch news release …
9 Likes
wait until it’s stable and check it out, OP
no one can really give much information about it because not many people have really used it
1 Like
As for the question whether GraphQL is suitable for applications with sensitive data: absolutely! GraphQL just describes a server API, much like REST. It is therefore just as secure as traditional REST. I would even argue that it’s easier to secure a GraphQL server than to secure REST endpoints, because it can support the same applications as a REST API, but with fewer endpoints.
3 Likes
As long as MongoDB is used, it has no place in financial services. Mongodb is too unreliable for that.
For that you want a database which has been built from the ground up with reliability in mind. And not something where it has been tacked on as an afterthought.
2 Likes
ahh right i’m currently learning rest stuff…
it is said that rest queries are validated against a schema… then theoretically the queries will more secure than queries from naked db…
Apollo will let you use any backend you like: Postgres, MySQL, Mongo, Redis, Cassandra, flat files, REST services, etc. Because it’s built on GraphQL, it will let you compose various backends into a type system that you can query with one simple language.
That said, I’m assuming you were referring to Meteor only supporting MongoDB for the moment, which is true.
I think @rhywden was talking about MongoDB itself not being reliable enough for this kind of application. That won’t be fixed by schemas alone. The main issue is not even security, but the safety of your data: making sure that nothing is lost. MongoDB has historically not been great at that, but I don’t know if that’s still true at the moment. That said, unless you’re thinking about processing financial transactions or any other highly sensitive information through this system there could well be a part of it that is best built in Meteor. It really depends on your use case.
3 Likes
Banks still use Fortran - they won’t switch anytime soon. Programs are running today, written by people long dead, and kept alive by some concoction of youthful spirit, cases and cases of redbull, and unhinged greed. I highly doubt they would use Meteor anytime soon.
This is not Meteor’s fault, it’s just the way banks are operated. Every decision is meticulously scrutinized and put to comitee.
1 Like
i think it’s depend on who’s the decision maker and culture of the company…
if they aware that technology could be a huge boost for competitive advantage then they will always welcome to consider new technology…
Nah, I don’t think so. There is too much legacy Fortran code to migrate to something else. It’s the reason why a Fortran developer still exists, and why they command such a huge paystub.
1 Like
I guess so thank you…
You might want to read this:
1 Like
Not all banking development is done in Fortran…they have lots of COBOL too (kidding). Old mainframes are typically COBOL or Fortran, but there’s a lot more than just old mainframes to a bank’s infrastructure.
1 Like
hi there ! that’s great, I will have a job for a long time !! Seriously, I am also a Fortran developer , and I think that this is not that an old language (the new Fortran 2008 standard is a really powerful language). However, it is not made for the web (not yet).
1 Like
Because there’s been a lot of FUD around this topic, and it reads just like parroting something you heard around the water-cooler. Obviously, if you have actual data or experience around this, please feel free to cite.
There are certainly issues with MongoDB, as there are with any database system. But I don’t think throwing around blanket statements like this helps progress the discussion.
To answer the original author’s question - are you able to provide any more context around what you mean by “financial service(s)”? Because that’s a pretty broad area, and covers a lot of potential use-cases.
(I have worked in financial services, and I was also previously at MongoDB.)
1 Like
It’s always nice to hear someone parrot the term “FUD” because someone’s saying something you don’t like.
Something like “Fire and forget” queries where you have to query yourself actively for errors are not something which inspire confidence in me. For reliability, you want the pessimistic approach - which means throwing errors and warnings when something goes wrong by default. And not a “forgot lastError()? Whelp, here goes the data!”
Also, stuff like this: https://aphyr.com/posts/284-call-me-maybe-mongodb
Somewhat newer: https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads
In this post, we’ll see that Mongo’s consistency model is broken by design: not only can “strictly consistent” reads see stale versions of documents, but they can also return garbage data from writes that never should have occurred.
1 Like
Can I ask - were you actually affected by any of these issues you mentioned? Or was it just something you read on the internet? The reason I ask is because it fairly easy to have a productive discussion around the first - the latter is a bit harder.
However, I’ll give you the benefit of the doubt =), and assume this is from your firsthand experience.
Normally, when somebody claims " is too unreliable for that", they’re referring to actual cases where a database lost data - as in, you wrote data in, it was confirmed as persisted, and then when you went to retrieve that data, it either wasn’t there, or you got incorrect results.
Your first example - “fire and forget”, I assume you’re referring to the getLastError command. In older versions of MongoDB, write operations were usually done in two phases - one, to send the data to the server, and another separate call to retrieve the status code.
I may be able to shed some light here - MongoDB was actually originally part of a PaaS stack (hence the original company name 10gen). Eventually, they decided that the data persistence layer (i.e. what became MongoDB) was useful on its own, and spun it out into its own product.
For historic reasons, other parts of the stack were responsible for checking write concerns. Hence, when MongoDB was spun out as its own product, it was the responsibility of the developer to ensure they either made the appropriate calls themselves or set the write concern to an appropriate value, if their app couldn’t make the calls.
Of course, just because you didn’t follow the documentation doesn’t automatically meant you lost data - it would only happen if say, your network lost the packets in transit, or the box rebooted at the wrong moment. Then again, some of those events could be quite likely, in some environments.
This was documented from the beginning, and from memory, I think MongoDB had pretty clear warnings around it (although there’s arguments to be made on whether they were bold enough). Unfortunately, a lot of people glossed over it, or just deployed the product into Production without having time to read the documentation. So in version 2.4 the defaults were changed and if you wanted the old behaviour, you had to explicitly set that.
Your second example - you point to Kyle’s posts, where he dissects various database engines. I have a lot of respect for his work, and I’m not going to try to dissect it all - people far smarter than I have already discussed this openly - in fact, shortly after this post, Kyle filed a bug-report in the MongoDB bug tracker - you can see it right here:
https://jira.mongodb.org/browse/SERVER-17975
And there’s a fair amoutn of discussion between him and various developers on what the implications of his investigations are.
However, I think it’s quite disingenuous of you to mention Kyle’s post on MongoDB, then fail to mention that he’s made similar posts about most other database engines (RethinkDB, MySQL-derivatives, PostgreSQL, Riak, ElasticSearch, RabbitMQ, Redis etc.) and all of them have various issues, to varying degrees.
As I said in my first post:
There are certainly issues with MongoDB, as there are with any database system. But I don’t think throwing around blanket statements like this helps progress the discussion.
You came out swinging, and said “MongodB is too unreliable”, with no data or evidence to back your claim. I think you did the community a disservice, by not either providing at least some evidence for your claims, or some explanation for why you felt that way, and/or what you thought was a better choice. It’s very easy to just say “X sucks”, but harder to actually say “X sucks because of ABC”, or “X sucks, and I think we should do Y instead because of ABC”.
I don’t know if anybody can categorically say whether MongoDB was the “right” choice for Meteor - although I suspect in many ways it played well into the whole “easy to get started” vibe of Meteor. However, if you’d like to progress the discussion, you really need to step up.
7 Likes
Sorry, a “but the others do it too!” is a very weak excuse.
I’m no expert on that stuff, so I’d like your opinion, if you will:
My app has ‘internal wallet’ system when customers can deposit money on their internal wallet (account) and then use this wallet to pay for different services offered by the app.
I’d like to log transactions occuring when customers deposit money to internal wallet and when they pay for internal services.
Is mongoDB good enough for that?
And if yes - under what conditions should mongo become unreliable and require another db solution?
Thanks!
1 Like