How did you rebuff the lack of testing? The usual show stopper.
You should take a look at @awatson1978’s https://clinical.meteor.com track. Though it is tuned towards HIPAA certifications (and some very close minded stake holders), it can be an orientation.
PS: I gave up marketing Meteor. If I do, I try to advocate node on which meteor happens to run on top. And there are many big example corps that use node.
Lack of a “Standard” way of testing hasn’t been as much as an issue with Corporate devs in my experience, however i’d love MDG or the community to nail this, but until then Mocha, Jasmine and Velocity have been my tools of choice.
Playing the NodeJS card really helps when i’m discussing integration with other platforms and technologies, dropping a call to a SQL server or a Sharepoint API in a Meteor method using a node module really illustrates the point.
If you create some good content about using Meteor in an enterprise environment, I would sure love to have that on the website or the Meteor Guide somewhere.
That’s fair. They are close minded to some extent (malpractice lawsuits will do that to an organization).
Part of the issue is that they’re comparing Meteor to the SDKs from IBM, Microsoft, Oracle, GE, Philips, Epic, Cerner, etc. Those organizations all have very mature quality-control processes (if not Six Sigma initiatives). By comparison, Meteor and the Node community are much more of a freewheeling anything-goes environment.
Also, the funding/hosting landscape is very different for enterprise/corporate users. Corporations are generally trying to expand into new markets rather than establish themselves as viable startups; so the budgets are bigger and teams are larger; teams with more people means diversity concerns and working with different experience levels; apps have to exist in pre-existing workflows and pipelines; interdepartmental responsibilities and turf wars mean choices of IDEs, datacenters, rendering view layers etc are constrained; and so forth. Lots of non-technical project management factors start becoming relevant.
But yeah… otherwise we’re doing mostly the same thing. The clinical.meteor.com site is a bit outdated, and not the best go-to resource right now for diving into the release. The clinical-meteor/cookbook is probably the better resource until next month when we’re going to do a major update to the project homepage.
Abigail, absolutely no critique intended. I understand that you cater to the specific taste of a specific industrial branch of specific stakeholders with the clinical track. And that is great. But that is certainly not relevant for i.e. an indispensable ITIL certification for a modern information system / integration.
Saying that, the prioritisation is misaligned for most corporates outside of your relative small target industry (in the sense of IS), given that the vast majority of countries also don’t suffer under a common law system that may find malpractice linked to api wording. Do you have a link to such a case? I would be interested to know. Here at the University of Cologne, we do research and collaborate on HIPAA/HITECH compliant cloud service certifications.
Getting meteor really on paar with Mongo and Node (while Node… already dragged its feet due to the committee issues in the io (re-)merger) would be a tremendous amount of work and only really feasible when meteor is either
Personally I would love (and tried) to bring Meteor into the finance / insurance / certification world as a pluggable system, since there is a lot of dynamic data-loading going on that only falls under the table because current turnaround times are too long for product or service specific tasks or are prey to security no-go’s. Something that Google tries/d to aim for with App Script and App Engine but falls short front and center due to compliance issues.
Thankfully, official testing is coming with Meteor 1.3. Very interested on what “strategies” others might come up with.
Great idea. I’m using Meteor in an enterprise context as well and would buy the book. I’m working in a PMO and did some interfacing with Planview and SQL Server to enhance and streamline certain weak spots (such as project proposals) and made pretty sunburst graphs with D3 for capacity planning and analysing some stuff. So if you need some input in this direction feel free to contact me.
And maybe you could enlighten me about a simple AD authentication method.
Hi crenshininbon,
would be very interested in sharing and potentially collaborating on that topic. We work with many clients in an enterprise environment and I do recognize all of the issues and “to-do’s”. However there is a lot of wiggle room in the corporate landscape where even as-is Meteor apps would be an improvement vs. Excel spreadsheets and confusing Sharepoint list mashups.
We certainly should follow the Mantra architecture objectives as they address many of the enterprise readiness aspects. And certainly corporate authorization and more divers DB integration (e.g. via GraphQL) are at the top of my list.
And I think above all it’s standards and perceived future proofed solutions more than features that drive corporate technology decisions.
Cheers
-Tom
Hi Tom,
actually I haven’t taken a deeper look at Mantra. I’m using plain ‘mup’ for deployment and Kadira to some extent.
The apps are running on “office servers” for simplicity sake, since our IT provider is somewhat cumbersome to deal with. Many regulations that don’t allow for continuous change and easy dev flow, like no internet access for servers in the data center.
To circumvent that and still gain acceptance, I build up things really quickly (measured by our corp standards). From very sketchy requirements and insights in their current processes. I Show them value very soon, to woo them and adjust direction as needed (I often see the question in their eyes: how did he get that done so fast?)
The app is not very stable at the beginning. Hardening happens as I go. I don’t have the requirements for 24/7 operation and 99,99% fault tolerance so it’s not so hard at all. Data loss is the biggest concern and that can be easily mitigated with regular dumps and offsite storage of them.
For DB integration … well I was concerned about that as well. But I found it easier to deal Meteor internally with the Mongo way and load/store data from/to other DB types on the server side utilizing the existing npm ecosystem. It’s always deciding by case. What data is needed? When? How fresh? To what detail? I usually end up with importing stuff. Deciding which system is the leader, in terms of data correctness and actuality and make the other system adapting towards the leaders information.
I don’t actively promote Meteor. It´s more subtle. I include usually a footer “Made with Meteor” though. But I don’t tell the decision makers I programmed that all by myself with Meteor.js. That won’t tell them anything. If they ask I’m happily explaining but I always have the impression they don’t really understand and/or care.
For them it’s “Yeah, we got that pesky patchwork-process streamlined, simplified and automated as far as feasible! And it is really accepted by the participants without any complaint!”. And that’s all they care for. It’s not the main business after all.
All that said, I think it’s so easy going for me because of my special in-house position. I don’t have to be paid on top of the usual expenses. So they care less what’s actually done with the money.
Regards
Dirk
EDIT: You might have read between the lines that easy and fast MVP is a prime concern for my way of doing enterprisy-development. And any heavy burden (which Mantra and GraphQL feel after a glimpse) that slows me down is going to potentially thwart my approach.
They’re separate things. The issues around API design aren’t a HIPAA issue. They’re an EEOA issue. HIPAA is a regulatory burden that applies to medical practices. However, if a medical practice employs other people, it’s also subject to EEOA.
There’s been a couple of requests for a link with applicable case law, so here’s an official document from the Equal Employment Opportunity Commission providing guidance and instruction to organizations large enough to require an EEOC Compliance Manual. This is one of the many documents and policies that we (as a hospital) had to take into consideration when selecting technologies, applications, SDKs, and the like:
http://www.eeoc.gov/policy/docs/national-origin.html
In particular, Example 12, 13, 14, 15, 16, 17, 18, 19, and 20 are all potentially relevant to the question of API wording. As you will see, EEOA case law specifically deals with language, dialect, and accent in the work place; language requirements; etc. Which is exactly what API design is. Just replace ‘English’ or ‘Spanish’ with ‘Javascript’ or ‘Meteor’ or ‘Python’ or ‘.Net’, etc. And keep in mind that universities now often allow programming languages to meet foreign language requirements.
I could provide multiple accounts of how I’ve personally seen this play out in the workplace with real teams, real budgets, and real APIs. But for brevity’s sake, just consider Mongo’s deprecation of setSlaveOkay() in favor of the much less controversial secondaryPreferred(), and how that came about. My contention is that API deprecation was a result of friction in the marketplace and EEOA considerations.
I think some of the chatter that comes up in enterprise is really the mis-trust in new things that are not built by older school enterprise leaders - oracles, ibms, informaticas - many ways it comes down to reducing risk, decent support, scaling and great security. Nodejs for rapid prototyping is amazing and it’s cool to see some large orgs. using it. Meteor makes that process even faster - but I think the meteor team has some hard work to do still to convince enterprise (if that’s even their goal) I could see meteor being used for internally built tools in large enterprise - reactivity being a key feature.
We’re about to launch a new digital workplace initiative, revamping a whole load of enterprise apps and provide vastly improved user experience, data aggregation, cloud web app integration etc. Gaining insights on the two points above would be incredibly useful and valuable.
I know for a fact many developers have integrated Meteor with various enterprise services. But it’s not something that is built in out of the box.
It should be their goal if they wish to be a commercially viable company. I worked as a developer in IBM Global Services in my previous full-time job, and worked on big projects for corporate clients. The clients are willing to pay top rates for quality (including labor), and project budgets are often into the multi millions.
Now that I’ve immersed myself into the Meteor world, I see huge disparities that need to be addressed. More people from the corporate world are going to discover Meteor as it continues to increase in popularity, so MDG need to work on marketing Meteor as a serious and robust platform that meets their needs and expectations, instead of remaining to be perceived only as a frivolous play toy for programmer nerds to tinker with.
Some of the concerns that I have had are:
Low attention to security. It’s not entirely MDG’s fault, it just seems that the general community, including package developers, don’t care much. Would that statement apply to the open-source developer community in general? I’ve come across many code examples that would open up security vulnerabilities in an app. Maybe most people are just developing apps in which there’s nothing for a hacker to gain financially, e.g. posts and comments apps. If that’s the case, it may have become a chicken-and-egg situation - If most people are developing posts and comments apps then development of Meteor security becomes low priority because the demand for security is low amongst most developers; on the other end, people who need to develop a highly secure app that involves e-commerce / monetary transactions may perceive Meteor as a low-security framework / platform because of the lack of attention to security (or they sense that most Meteor apps are frivolous “play” apps), and therefore choose not to use Meteor.
The security section in the Meteor Guide, and introduction of ValidatedMethod are good steps, but more needs to be done. MDG should take the lead in raising the level of security consciousness in the community and industry, up to the point at which they can market Meteor as a high-security framework / platform. The notion that Meteor is not appropriate for apps that require high security should be turned around 180 degrees. Offering high security out-of-the-box (or at least making it very easy to configure (like how they’ve made real-time data over the web easy)) will definitely increase uptake across all sectors, including corporate.
ACID transactions are not possible with MongoDB. i.e. there’s no commit / rollback functionality. The can lead to data inconsistency when two or more collections are meant to be updated at once but one update fails. MDG / Meteor has not offered any official solution at the application level. There is the meteor-transactions package by babrahams that looks like the best solution, but even he warns “do not use it to write banking applications or anything like that. Seriously, don’t.” What we would rather see is a solution that can confidently proclaim to solve the lack of ACID transaction support in the data layer. MemDB for Node.js looks great, but I’m not sure how to set it up with Meteor. This really needs to be solved.
Imprecise financial calculations. This is not MDG’s fault but JavaScript’s. For precise calculations, Java offers
BigDecimal. .NET offers decimal, and even explicitly proclaim in their reference documentation that it is “appropriate for financial and monetary calculations”. JavaScript only offers a floating point. If you type 0.1 + 0.2 in your browser console the result is 0.30000000000000004. Some people might say “just round the result off to 2 decimal places”. But that’s not a comprehensive solution. Type 0.1 + 0.2 === 0.3 in your browser console to see what you get. Most people would expect to see the result true at first glance, but it’s false. This makes comparing monetary values in JavaScript potentially troublesome.
There are some Node packages for precise financial calculations, however many assume that you are only working with 2 decimal place numbers and simply multiply or divide the number by 100 to calculate using integers, so they are not appropriate for doing calculations with numbers that may have variable decimal places (e.g. currency exchange rates - EUR/USD may have 4 or 5 decimal places, USD/JPY may have 2 or 3 decimal places). I’ve been using bignumber.js, and it does the job very well, but it doesn’t work frictionlessly with other packages, mainly because JavaScript is not strongly typed. I’m still trying to work out the best solution.
What is good is that IBM has been taking notice of Meteor and some IBM employees have spent time trying it out and have written technical articles about it. Searching for “Meteor” in the Bluemix Developers Community brings up quite a few Meteor-related pages. e.g.:
Tips for running Meteor.js on Bluemix. A notable quote: “we’ve also seen an uptick in the number of clients interested in Meteor”
Deploying your Meteor app to Cloud Foundry and Bluemix
Instant web applications with Meteor
IBM developerWorks MeteorJS community
This is evidence that IBM are definitely interested in and are keeping watch of Meteor.
I had a thought that IBM could simply acquire MDG and Meteor (as they’ve done with many other companies whose technology they’ve been interested in), and wondered whether that would be good for Meteor. Maybe more resources could be assigned to Meteor development in order to make the necessary improvements for it to fit comfortably in the corporate world. IBM already owns Compose.io DB hosting and SoftLayer cloud hosting infrastructure, so basically they could own all technology required for a Meteor app, which would make it easier to ensure that all components of the stack work seamlessly with each other.
Anyway, MDG should consider engaging in frequent communication with the Meteor enthusiasts at IBM to gain deeper insights into the needs of corporate clients and work towards catering for them.
Generally, I agree with all of your points. In particular, strong typing and bigints really need to find their way into the stack.
That being said, I would ask whether developers of FileNet and ObjectStore were told across-the-board that they had to be ACID compliant, or if it was understood those products were simply being sold into specific market segments that didn’t need ACID compliance. (I ask having bought/installed millions of dollars of document/object storage from IBM in the past, and knowing that document management and storage doesn’t require transactions. It’s what brought me to Mongo and then Meteor in the first place.)
Why must Meteor also be a financial transaction system? Is it not enough that it works fabulously as the app layer for a distributed object/document store?
@crenshininbon, this reflect almost to the letter my enterprise environment and approach… including your EDIT: paragraph!
Floyd, It’s a great idea. It will help Meteor Developer (and of course meteor lovers) a lot 
There are differences between Object storage and databases, with each catering to different needs. Object storage is generally used for data that doesn’t change frequently and doesn’t need to be accessed and processed heavily on an ongoing basis. For databases, it’s the other way around. So if ACID transactions are required, a database is the assumed choice of technology.
Is MongoDB marketed as an object storage technology? Is it suited to store large binary files (including video and audio)? In Meteor it’s used more as a database for quick and frequent reading and writing of structured data.
Services like Object Storage or Amazon S3 (the world’s largest object storage system) may be more suited for storing large binary files.
When even in the view layer simple arithmetic is inaccurate, it’s a problem. e.g. A common task is to check whether a result of a calculation is 0. Rewriting the example comparison I mentioned before, the result of 0.1 + 0.2 - 0.3 === 0 is false, when just about anyone would intuitively expect it to be true, especially considering that computers are perceived to be highly precise. Imagine how a user feels when she is told that she has not paid enough for something when the numbers clearly show that she already has. Sure, there are ways to work around this problem as mentioned before, but it takes extra effort which shouldn’t be needed in this day and age. BigDecimal and decimal have been around for around a decade in the other languages. It would have been good if MDG came up with an official solution in Meteor to this primitive problem to save developers’ time.
Meteor does not need to be “a financial transaction system”, but any improvements made towards becoming one would improve all apps as well as the marketability of Meteor, including to the corporate world.
Yes and yes. Look up BSON and GridFS when searching the Mongo docs. And there has long been the CollectionFS package in Meteor supporting both.
I take your point that general improvements help everybody ou, though.
For what it’s worth: In the company I work for, Meteor is being used in a product for control rooms of nuclear reactors (!), (air) traffic control, news stations etc. So it sounds quite convincing if you say Meteor is being used in nuclear power plants 
But in all seriousness, I think the graphql integration is pretty important for corporate adoption. Not only because it enables other types of databases (old-fashioned SQL, you know), but also because big companies tend to want to limit the amount of technologies they use (since they want to shuffle employees around, organize trainings, etc). The new data layer seems to work towards that goal by making Meteor suitable for a larger number of applications.
Hi Floyd,
I’m extracting SAP data on (almost) daily basis with node-sapnwrfc and inserting it into MSSQL with seriate.
About a year ago I started with meteorhacks:npm and node-rfc on linux. After I got async (fibers) stuff done right all went fine. Moreover, fibers became my favourite pattern of writing async code.
Currently I’m about to extract data from approx 200 QuickBooks files using ODBC into Mongo and map/reduce it to MSSQL for use in proprietary accounting software. It will be a Meteor app.
There is an excellent talk about development of “line of business” applications which I believe the way to make corporate IT life much more meaningful than just restarting Outlook every time it hangs or not synching emails.
So, if you (or someone else) need help with in-corporating Meteor give me a call 
Best regards,
Alex