I recently wrote about my journey to Meteor, deciding for it, as the basis for the development of an in-house app. Well, I drew a somewhat rosy picture of Meteor. As always, when something shiny new hits the stage. But you know, if I would have learned only one thing the last 15 years, stuck waist-deep in the software-world, it would be: there is no perfect solution, no silver bullet, not even a best practice.
It started to get a little messy, when the idea, to replace the planned Xtend based API to our legacy project-portfolio-management-app, with a lean solution integrated into Meteor, struck me. Initially the Meteor app should make REST/JSON requests directed to the API, which is still in development and has to be extended to incorporate the requirements originating from the development of the Meteor app.
Before I can go on, I have to confess: I have the tendency to over-abstract. That said and provided with the fact, that I worked on the API for some weeks now, with no clear usage scenarios drawn out, you might imagine how the API code looks like. Actually the API is used in other integration projects, so it is not useless, per se. It just feels, from the distance of a few days Meteor-hacking and much more understanding of what I still need from the API, way to abstract and in the consequence to complicated.
Well, I should have learned that by now. There are three factors that let me always loose sight of the bigger picture: getting lost in nitty-gritty details of bending technology to my will, not knowing exactly what is truly needed and working basically alone.
A few month ago, when I decided to make the API and take the Xtend-(Java)-jTDS route therefor, I also found Tedious, if I remember right. But it wasn’t really working back then. It still has some flaws. The documentation says, that there should be a ‘done’ event when all rows of a request are fetched, but my callback was never called. As I learned just now, those ‘done’ events (there are more: ‘doneProc’, ‘doneInProc’) are somewhat low-level and not really defined through the way of invoking the request. You are supposed to use the constructors callback to execute something when the query finishes.
OK. I can query the database. But how do I put the Tedious NPM package into the Meteor environment. Here it comes:
- Go to your Meteor projects folder.
- “cd .meteor/local/build/server”
- “npm install tedious” – you might have to prepend sudo, if you get errors. I had to use sudo on Ubuntu, on my Mac it worked without it.
I have found this steps in the answer to a StackOverflow question. To use the package you have to ‘require’ it. That works a bit differently in Meteor than usual. You have to use:
tedious = __meteor_bootstrap__.require(‘tedious’)
You can use ‘tedious’ now to create Connection and Request objects like in the example from above and query the database. But there is still one thing missing. If you try, for example, to put the received data into a Meteor collection you will get a nasty error, stating that you are not in the same fiber.
Node is inherently asynchronous, so are most of the packages. Meteor is different, there the server code runs in a single thread per request, it uses Fibers underneath to accomplish this behaviour. I usually like the async-style of Node more, but synchronous feels right in Meteor. So what to do? This guide has the answer. You have to use Futures. A Future is basically a tool that allows you to wait, until the result of an async call has returned. See the next gist for an example of using a Future, while a database is queried using Tedious. Putting the results into a Meteor collection:
Update: I made a new post, displaying the Npm-way you can take since Meteor 0.6.0.