As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have to write a new web application and currently am in the process of deciding on the architecture , there are several things i know i want to be able to do :
All machine must be symmetric , i.e. : commodity machines no custom build servers (aws)
I want a ReST API that is seperated from the UI as i allready have three clients for the API : mobile applications , the web site and a server from a 3rd company waiting for the product to be build
it needs to able to scale horizontal (a but of a repeat of 1)
Easy to maintain : no time to learn new languages , more available candidates but willing to adopt new technologies
here is the basic architecture i've come up with :
frontend combining of nginx+nodejs+expressjs+YUI ,
api : nginx+tomcat+spring framework stack (rest+Security+core+aop)
the frontend will talk to the api with oAuth 2.0
nothing exciting about the api i've done it before , i know it works and works well would have loved to put some scala flavour but i don't have the time .
my main concern is the frontend : nodejs is insanely exciting and i've been playing around for some time also love the fact it's in JS , but i'm afraid about navigation+templating+sessions (for authentication only : stateless,stateless,stateless)+logging+debugging of it , if it works it works well but it's not a mature enviourment to develop in .....
anyone here developed a full frontend with stack or subsets of it ? any other suggestions to choose from ?
thanks guys .
but i'm afraid about navigation+templating+sessions (for
authentication only : stateless,stateless,stateless)+logging+debugging
of it
navigation? Not sure what you mean here. Use hyperlinks. AFAIK there's nothing in node like Rails' form_for() type helpers, but those were never that interesting to me. If you want something like Rails style before/after filters, say for requiring a logged in user, connect does this great.
app.all('/app/*', requireUser)
That will call requireUser for any path starting with /app. Inside requireUser you can make sure req.session.user is there (and maybe has proper authorization). If so, you call next() and the middleware responsible for actually generating the response is executed. If the user isn't logged in or is not authorized, you can generate a 30X redirect response and don't call next(). Done. There's a great example exactly like this in the express.js guide. Search for loadUser. This design is really elegant, IMHO.
templating? Uh, node.js has as good or better templating options than any other platform. Try jade or any of a dozen others. You can use the same templates on the server and in the browser, which is a nice win. Check out this video of Dav Glass using YUI widgets on the server side in node.js since you like YUI.
sessions? Connect sessions. Taste great. Less filling. What's the problem?
logging? Winston works for me. There are also fancier libraries as well I think.
debugging? node-inspector gives node.js (IMHO) the best debugging support available. It debugs with chrome's inspector and is every bit as awesome as debugging client side javascript. I can also debug server side unit tests when running via jasbin.
Here's an answer to what companies are using node.js in production.
So if you got problem with testing then you just misunderstand some features of Node.js and express. For example you can use something like this for testing:
app.get('/route', function(req,res,next) {
require('./controllers.js').method(req,res,next)
});
Then you need to drop cache with all files required in your controlles.js:
if (require.cache[__filename])
{
var del = false;
for ( i in require.cache)
{
if (i == __filename)
{
del = true;
}
if (del)
{
delete require.cache[i];
}
}
}
So now your controller will updated instantly to current version when request pass.
To understand how does nodejs require work just try this:
require.js
module.exports = {};
main.js
var x = require('./require.js');
x.tell = true;
var y = require('./require.js');
y.tell = false;
console.log(require('./require.js'));
Related
In my company, we're using Spring Boot to implement backend API and React to implement frontend including Web interface and Android/iOS apps.
Since our product is an Enterprise software, customers actually have to pay to get the latest backend API to deploy on their own servers. However, our mobile apps are regularly updated on the App Store. This leads to a situation where the mobile apps on end-users' devices may be the newer version while the backend API on the customer's machine is the older one. We plan to support up to 3 minor version backward, meaning FE 5.4 will support up to backend 5.2.
The backend does have an endpoint to return the current version number. However, I'm a bit clueless as to how our frontend implementation can maintain backward compatibility with older API versions as we add new features and may introduce breaking changes in backend API.
I completely understand there might not any beautiful solutions for this problem. I'm hoping if you've gone through this pain, you can share your experiences about what you've tried, the final approach that you took and the potential pitfalls to look out for.
I'm sure myself and other people who's running into this issue would be really grateful :).
Your solution will be similar to any frontend solution that uses Feature Toggle but I can already imagine that it will not be pretty.
Basically inside your code you'll have a lot of if/else statements or some form of wrapper that does the same underneath for every piece of UI/logic/functionality that is a breaking change on version upgrade.
I'd suggest that for every layers that you have (UI, logic, API call) you should start to have switches based on version returned by backend. You'll end up with a lot of redundant looking codes and a lot of codes that looks like this. (if you support only two versions. Use switch if you have more versions)
render() {
{version === "1.0.0" ? <VersionA /> : <VersionB/>}
}
You can however, write a utility method that wraps and returns different components based on versions. By doing that you can more easily remove components that you no longer need to support in the future.
const versionSwitcher = (version, ...Components) => {
switch (version) {
case "1.0.0":
return Components[0];
case "1.1.0":
return Components[1];
}
}
This of course, increases complexity throughout all layers but given your case I can't see it being simple. A good thing to do is to try to keep your own viewModel and never pass response from API directly into component. That reduces the coupling between API and your components and will make this a little easier.
I've been thinking about learning how to make simple Mac OS X applications based on web-technology and I came across node-webkit which seems compelling. However, I've recently invested in learning the basics of Sinatra/Ruby and I wanted to stay on that course.
Is there a "node-webkit equivalent" for developers who use Sinatra? Or, is there a recommended way to use the Sinatra framework (or Ruby) to build OS X apps that are essentially web wrappers?
Sinatra is a server-side framework.
Contrary to Node-webkit which is on client side.
If you need to interact with a server, you can still use sinatra (as well as node.js, php, ...) on your server.
But if you are looking for a framework like sinatra on node.js, you should look into Express.js : https://npmjs.org/package/express
Node-webkit can use file or http, and which to use depends on your needs. The majority of the time you shouldn't need to, Node-webkit runs completely client-side using only HTML, javascript, and css. You certainly can initialize a local webserver when Node-webkit loads, but first try making a basic "Hello World" application to learn how it works.
If you still think you need to spin up a web server, then the code might look something like this (I'm using Express.js):
// Retrieve libraries...
var expressPort = 6014
var NodeWebkit = require('nw.gui');
// Call focus to application...
NodeWebkit.Window.get().focus();
// Instantiate the Express Server...
var spawn = require("child_process").spawn;
spawn("node", ['./server/server', expressPort]);
// Request director page...
window.location.replace('http://localhost:'+expressPort);
In order to use the Node-webkit features from a page on localhost you will also need to add the following line beneath the root of your package.json:
node-remote": "<local>
Note: While this does work, you must really consider whether it makes sense. In other words, is you application fully self-contained? If nothing will access that content except the application then you don't need it.
For my application I am using Node-webkit as an admin console for creating/managing broadcasts. (hence the local webserver)
Nw is not a web framework. Nw does not use a http protocol; it does use a file protocol.
Nw is composed of chromium and nodejs, which allows you to run both DOM and node.js stuff -- without setting up a web server.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I don't see how to do test driven development in meteor.
I don't see it mentioned anywhere in documentation or FAQ. I don't see any examples or anything like that.
I see that some packages are using Tinytest.
I would need response from developers, what is roadmap regarding this. Something along the lines of:
possible, no documentation, figure it out yourself
meteor is not built in a way that you can make testable apps
this is planned feature
etc
Update 3: As of Meteor 1.3, meteor includes a testing guide with step-by-step instructions for unit, integration, acceptance, and load testing.
Update 2: As of November 9th, 2015, Velocity is no longer maintained. Xolv.io is focusing their efforts on Chimp, and the Meteor Development Group must choose an official testing framework.
Update: Velocity is Meteor's official testing solution as of 0.8.1.
Not much has been written about automated testing with Meteor at this time. I expect the Meteor community to evolve testing best-practices before establishing anything in the official documentation. After all, Meteor reached 0.5 this week, and things are still changing rapidly.
The good news: you can use Node.js testing tools with Meteor.
For my Meteor project, I run my unit tests with Mocha using Chai for assertions. If you don't need Chai's full feature set, I recommend using should.js instead. I only have unit tests at the moment, though you can write integration tests with Mocha as well.
Be sure to place your tests in the "tests" folder so that Meteor does not attempt to execute your tests.
Mocha supports CoffeeScript, my choice of scripting language for Meteor projects. Here's a sample Cakefile with tasks for running your Mocha tests. If you are using JS with Meteor, feel free to adapt the commands for a Makefile.
Your Meteor models will need a slight bit of modification to expose themselves to Mocha, and this requires some knowledge of how Node.js works. Think of each Node.js file as being executed within its own scope. Meteor automatically exposes objects in different files to one another, but ordinary Node applications—like Mocha—do not do this. To make our models testable by Mocha, export each Meteor model with the following CoffeeScript pattern:
# Export our class to Node.js when running
# other modules, e.g. our Mocha tests
#
# Place this at the bottom of our Model.coffee
# file after our Model class has been defined.
exports.Model = Model unless Meteor?
...and at the top of your Mocha test, import the model you wish to test:
# Need to use Coffeescript's destructuring to reference
# the object bound in the returned scope
# http://coffeescript.org/#destructuring
{Model} = require '../path/to/model'
With that, you can start writing and running unit tests with your Meteor project!
Hi all checkout laika - the whole new testing framework for meteor
http://arunoda.github.io/laika/
You can test both the server and client at once.
See some laika example here
See here for features
See concept behind laika
See Github Repository
Disclaimer: I'm the author of Laika.
I realize that this question is already answered, but I think this could use some more context, in the form of an additional answer providing said context.
I've been doing some app development with meteor, as well as package development, both by implementing a package for meteor core, as well as for atmosphere.
It sounds like your question might be actually a question in three parts:
How does one run the entire meteor test suite?
How does one write and run tests for individual smart packages?
How does one write and run tests for his own application?
And, it also sounds like there may be a bonus question in there somewhere:
4. How can one implement continuous integration for 1, 2, and 3?
I have been talking and begun collaborating with Naomi Seyfer (#sixolet) on the meteor core team to help get definitive answers to all of these questions into the documentation.
I had submitted an initial pull request addressing 1 and 2 to meteor core: https://github.com/meteor/meteor/pull/573.
I had also recently answered this question:
How do you run the meteor tests?
I think that #Blackcoat has definitively answered 3, above.
As for the bonus, 4, I would suggest using circleci.com at least to do continuous integration for your own apps. They currently support the use case that #Blackcoat had described. I have a project in which I've successfully gotten tests written in coffeescript to run unit tests with mocha, pretty much as #Blackcoat had described.
For continuous integration on meteor core, and smart packages, Naomi Seyfer and I are chatting with the founder of circleci to see if we can get something awesome implemented in the near term.
RTD has now been deprecated and replaced by Velocity, which is the official testing framework for Meteor 1.0. Documentation is still relatively new as Velocity is under heavy development. You can find some more information on the Velocity Github repo, the Velocity Homepage and The Meteor Testing Manual (paid content)
Disclaimer: I'm one of the core team members of Velocity and the author of the book.
Check out RTD, a full testing framework for Meteor here rtd.xolv.io.
It supports Jasmine/Mocha/custom and works with both plain JS and coffee. It includes test coverage too that combines unit/server/client coverage.
And an example project here
A blog to explain unit testing with Meteor here
An e2e acceptance testing approach using Selenium WebdriverJS and Meteor here
Hope that helps. Disclaimer: I am the author of RTD.
I used this page a lot and tried all of the answers, but from my beginner's starting point, I found them quite confusing. Once I had any trouble, I was flummoxed as to how to fix them.
This solution is really simple to get started with, if not fully documented yet, so I recommend it for people like myself who want to do TDD but aren't sure how testing in JavaScript works and which libraries plug into what:
https://github.com/mad-eye/meteor-mocha-web
FYI, I found that I also need to use the router Atmosphere package to make a '/tests' route to run and display the results from the tests, as I didn't want it to clutter my app every time it loads.
About the usage of tinytest, you may want to take a look at those useful ressources:
The basics are explained in this screencast:
https://www.eventedmind.com/feed/meteor-testing-packages-with-tinytest
Once you understood the idea, you'll want the public API documentation for tinytest. For now, the only documentation for that is at the end of the source of the tinytest package: https://github.com/meteor/meteor/tree/devel/packages/tinytest
Also, the screencast talks about test-helpers, you may want to have a look at all the available helpers in here:
https://github.com/meteor/meteor/tree/devel/packages/test-helpers
There often is some documentation inside each file
Digging in the existing tests of meteor's packages will provide a lot of examples. One way of doing this is to make a search for Tinytest. or test. in the package directory of meteor's source code
Testing becomes a core part of Meteor in the upcoming 1.3 release. The initial solution is based on Mocha and Chai.
The original discussions of the minimum viable design can be found here and the details of the first implementation can be found here.
MDG have produced the initial bones of the guide documentation for the testing which can be found here, and there are some example tests here.
This is an example of a publication test from the link above:
it('sends all todos for a public list when logged in', (done) => {
const collector = new PublicationCollector({userId});
collector.collect('Todos.inList', publicList._id, (collections) => {
chai.assert.equal(collections.Todos.length, 3);
done();
});
});
I'm doing functional/integration tests with Meteor + Mocha in the browser. I have something along the lines of the following (in coffeescript for better readability):
On the client...
Meteor.startup ->
Meteor.call 'shouldTest', (err, shouldTest) ->
if err? then throw err
if shouldTest then runTests()
# Dynamically load and run mocha. I factored this out in a separate method so
# that I can (re-)run the tests from the console whenever I like.
# NB: This assumes that you have your mocha/chai scripts in .../public/mocha.
# You can point to a CDN, too.
runTests = ->
$('head').append('<link href="/mocha/mocha.css" rel="stylesheet" />')
$.getScript '/mocha/mocha.js', ->
$.getScript '/mocha/chai.js', ->
$('body').append('<div id="mocha"> </div>')
chai.should() # ... or assert or explain ...
mocha.setup 'bdd'
loadSpecs() # This function contains your actual describe(), etc. calls.
mocha.run()
...and on the server:
Meteor.methods 'shouldTest': -> true unless Meteor.settings.noTests # ... or whatever.
Of course you can do your client-side unit testing in the same way. For integration testing it's nice to have all Meteor infrastructure around, though.
As Blackcout said, Velocity is the official TDD framework for Meteor. But at this moment velocity's webpage doesn't offer good documentation. So I recommend you to watch:
Concept behind velocity
Step by step tutorial
And specially the Official examples
Another option, made easily available since 0.6.0, is to run your entire app out of local smart packages, with a bare minimum amount of code outside of packages to boot your app (possibly invoking a particular smart package that is the foundation of your app).
You can then leverage Meteor's Tinytest, which is great for testing Meteor apps.
Ive successfully been using xolvio:cucumber and velocity to do my testing. Works really well and runs continuously so you can always see that your tests are passing.
Meteor + TheIntern
Somehow I managed to test Meteor application with TheIntern.js.
Though it is as per my need. But still I think it may lead someone to the right direction and I am sharing what I have done to resolve this issue.
There is a execute function which allows us to run JS code thorugh which we can access browsers window object and hence Meteor also.
Want to know more about execute
This is how my test suite looks for Functional Testing
define(function (require) {
var registerSuite = require('intern!object');
var assert = require('intern/chai!assert');
registerSuite({
name: 'index',
'greeting form': function () {
var rem = this.remote;
return this.remote
.get(require.toUrl('localhost:3000'))
.setFindTimeout(5000)
.execute(function() {
console.log("browser window object", window)
return Products.find({}).fetch().length
})
.then(function (text) {
console.log(text)
assert.strictEqual(text, 2,
'Yes I can access Meteor and its Collections');
});
}
});
});
To know more, this is my gist
Note: I am still in very early phase with this solution. I don't know whether I can do complex testing with this or not. But i am pretty much confident about it.
Velocity is not mature yet. I am facing setTimeout issues to use velocity. For server side unit testing you can use this package.
It is faster than velocity. Velocity requires a huge time when I test any spec with a login. With Jasmine code we can test any server side method and publication.
Current Project Setup
I've been working on a web-based chat, similar to Facebook chat. At the current state, I listen for incoming chats and check for new messages in an existing chat is by doing...
setTimeout(function() { listenForIncomingChat() }, 500);
setTimeout(function() { checkForIncomingMessages( ...params... ) }, 500);
... so doing the setTimeout() makes sure these functions are always running. Depending on how many chat windows I have open, Firebug's console can go crazy with POSTs to the server :)
Obviously this is really inefficient, but it is the only way I could get things to work. Now I'm looking for the ways to make it better, to do it correctly!
Some Research
Now, I have heard about Comet Programming and that this is the way to open a long-lived HTTP connection with the server, but I'm not familiar with the technology or the ideas behind Comet. WebSockets for HTML5 is probably even better, but since that is not in full swing nor is it supported by all browsers, I'll stick with what works.
According to Wikipedia, there are several ways to develop with the Comet style: Streaming (hidden iFrame, XMLHttpRequest) or AJAX with long polling (XMLHttpRequest, Script tag). However, I don't know anything about this. I've also read about the AJAX Push Engine (APE) and it looks cool, but I don't want to use a third-party for the time being.
I've recently stumbled upon WebChat 2.0 so I'm going to be looking through the source code to try and understand how it all works.
On to the question(s)
So where can I find example code/tutorials on how to get started with this kind of project? How would I implement the Comet technique? How do I set up the long-lived HTTP connection with the server?
Here's an example of a chatroom using node.js, source code here.
I believe the client uses polling, but this example is interesting because the server side is in JS too, and node.js is efficient for this type of stuff.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'm looking for an easy way to debug RESTful services. For example, most webapps can be debugged using your average web browser. Unfortunately that same browser won't allow me to test HTTP PUT, DELETE, and to a certain degree even HTTP POST.
I am not looking to automate tests. I'd like to run new services through a quick sanity check, ideally without having to writing my own client.
Use an existing 'REST client' tool that makes it easy to inspect the requests and responses, like RESTClient.
At my firm we use a variety of different tools and approaches to testing RESTful services:
We write cURL scripts - essentially a single command saved in a file. One file per resource per method. For PUT and POST, we'll usually have files containing the representations to send alongside the cURL script. For example, for a mailbox resource, we might have a file named mailbox_post.cmd, which might contain the line curl -v -X POST -u username -H 'Content-Type:application/xml' -d #mailbox_post.xml http://service/mailbox. We like this approach because we end up building a collection of tests which can be run in a batch, or at least passed around between testers, and used for regression testing.
We use cURL and RESTClient for ad-hoc tests
We have the service serve XHTML by default, so it's browsable, and add forms resources, so the service is actually partially or fully testable using a browser. This was partly inspired by some parts of RESTful Web Services, wherein the authors show that the line between web services and web applications may not need to be as solid and strict as is usually assumed.
We write functional tests as Groovy closures, using the Restlet framework, and run the tests with a test runner Groovy script. This is useful because the tests can be stateful, build on each other, and share variables, when appropriate. We find Restlet's API to be simple and intuitive, and so easy to write quick HTTP requests and test the responses, and it's even easier when used in Groovy. (I hope to share this technique, including the test runner script, on our blog soon.)
Postman, a Google Chrome extension, may be helpful.
Edit years later: Also the website of the url in case Chrome extension link gets changed: www.postman.com
I've found RequestBin useful for debugging REST requests. Post to a unique URL and request data are updated/displayed. Can help in a pinch when other tools are not available.
https://requestbin.com/
A tool I've found useful if you're running OS X Leopard:
HTTP Client
It's a very simple GUI program that allows you to craft http requests to a resource and view the response.
cURL works just fine.
You can use fiddler's Composer to debug restful services..
Updated JD 12 sep 2013: Rest Builder is now called Composer.
I ended up settling on POSTMAN
It supports all REST features I could think of, and the UI is absolutely excellent. The only downside is that it requires Chrome.
RESTTest for Firefox (an add-on). Fiddler for IE.
I'm using Soap UI to test my REST API.
It is more complete than any other tools:
fine debug requests and responses
automated testing
all GUI based
properties and properties transfer to parameterize your tests
conditional testing
performance testing
I'm not working for SmartBear.
I was already a big fan of SoapUI while using it for SOAP WebServices.
Aside from using one of the tools in Peter Hilton's response, I would have to say that scripting the tests with LWP or some similar tool may be your only option. You could bypass the use of LWP by just opening a socket, sending a raw HTTP request in and examining what you get in return. But as far as I know, there are a dearth of testing tools for this sort of domain-- most look at this problem-space primarily from the lens of a web-site developer, and for them the browser is enough of a testing platform.
I use restclient, available from Google Code. It's a simple Java Swing application which supports all HTTP methods, and allows you full control over the HTTP headers, conneg, etc.
If you want free tool for the same purpose with additional feature of multipart form data submission it is here http://code.google.com/a/eclipselabs.org/p/restclient-tool/
Firefox's has RESTClient plug-in to send different request with methods, parameters, headers etc.
You guys should check poster extension for firefox, it's simple and useful enough to use :)
I tend to write unit tests for RESTful resources using Jersey which comes with a nice REST client. The nice thing is if you implement your RESTful resources using JAX-RS then the Jersey client can reuse the entity providers such as for JAXB/XML/JSON/Atom and so forth - so you can reuse the same objects on the server side as you use on the client side unit test.
For example here is a unit test case from the Apache Camel project which looks up XML payloads from a RESTful resource (using the JAXB object Endpoints). The resource(uri) method is defined in this base class which just uses the Jersey client API.
e.g.
clientConfig = new DefaultClientConfig();
client = Client.create(clientConfig);
resource = client.resource("http://localhost:8080");
// lets get the XML as a String
String text = resource("foo").accept("application/xml").get(String.class);
because its totally missing here:
https://luckymarmot.com/paw
Is worth ever penny...