I've been using Yeoman 0.9 up until yesterday when I decided to use the beta 1.0 release on OS X. I use Yeoman to develop an angular app.
With the Yeoman 0.9-->1.0 migration of my app done and working, I'm now keen to extend the dev server fired up by yeoman grunt server to allow me to make cross-domain calls to an API developed by another team, hosted on another server, where they've already allowed cross-domain calls. Up to now we've been using a fake http backend courtesy of angular.js.
--An aside--
If anyone's reading this looking for a quick solution, we got cross-domain calls working by passing the --disable-web-security option to Chrome from the command line using this approach on OS X with Chrome, but it turns off security for all of Chrome (thumbs down) and we can't get Chrome to fire up as a new instance anyway.
--End aside--
Through some digging I found this Stack Overflow post (via the answer to this post) giving me a pretty good idea on what I need to do to get grunt server allowing cross-domain calls.
It essentially involves adding a middleware component to connect to allow alter the headers so that "Access-Control-Allow-Origin" is set to "*" or whatever one likes.
Knowing nothing about Node.js, I can see the change alluded to in the post needs to be made somewhere in the many files created by Yeoman, but where? I've done some raw string searches for "app.configure" and "connect.listen" within the "node_modules" directory set up by Yeoman but I come up with a number of hits, most of which are from examples bundled with the modules and it isn't clear to me which I should edit. In case it helps, here's a snapshot of the directory structure for my angular app:
If anyone can give me some pointers on where these changes may be made I'd really appreciate it!
Solved sans messing around with node using the approach in this github pull request: http://github.com/angular/angular.js/pull/1454
You can use Apache proxy and connect your REST server with gruntjs(angular.js).
Apache would do this:
proxy / -> gruntjs
proxy /service -> REST server
you would use your application hitting Apache and angular.js application would think that is talking with itself so no cross domain problem.
Here is a great tutorial on how to set this up: http://alfrescoblog.com/2014/06/14/angular-js-activiti-webapp-with-activiti-rest/
Related
I want to use React for a project I am working on, but I also want to use an API.
How can I do it?
I have tried to Google this and ask different people, but I have not got a response yet, so I thought I would ask here. I want to use express and maybe not use create-react-app (as it takes up a lot of storage).
Working on a custom server doesen't preclude the use of an API.
If you want fetch the API from the express server and inject it directly on react frontend you need to enable server side rendering (useful post) and pass the data collected as a props from the server (check this example).
Rather then you can build your react project (using even create-react-app) and build an express server who return the index.html on call.
Personally I prefer the first one solution.
So I built an app I wanted with all blows and whistles including integration with OpenID Connect (OIDC "oidc-client").
Problem is it works only at DEV environment, since electron spins local server for it, so when I'm redirected after identification my app in DEV mode listense to "localhost:3000" and oidc-client can proceed with saving token and other things.
But, once I have built a production version, electron serves react as a static files, so all URL are now "file://....", and once I'm redirected after identification this time, no one is there to listen at OIDC callback at "localhost:3000". I drilled the docs of electron and OIDC but haven't found even one example on how to implement this case.
Anyone have successfully "listened" to callbacks at production version in Electron? The only option I have in mind is to spin up a server at prod and listen to "localhost:3000", but than the question is where to redirect it, so OIDC will catch it? I'll appreciate any input, thank you in advance.
Here some visual explanation of what I described.
Hmm - how are you packaging the app? I have a couple of Electron samples you could compare against, both of which you can run pretty easily against my cloud API and Authorization Server:
Loopback Sample using Plain Typescript
Private URI Scheme using React + Webpack
In both cases I can run a packaged app via 'npm run pack'. In my case I am using electron-packager to build release binaries.
I use AppAuth-JS and here is my code to listen on a loopback URL.
Not sure I fully understand your problem, but hopefully it gives you a few pointers.
I recently bought a new template for my site written in angular2, i did a short course on it and started to work and everything fine.
Now come the the part where i try to connect it to my DataBase and i cant figure it out...
after a little bit of reading i saw that i need to use nodejs in order to speak with the server side, is that true?
can i use php or i must use the nodejs api to work with my Db?
am i missing the concept of the angular2 or something? can someone post a basic script of angular working with php example , i just cant find it.. :(
thanks a lot :)
The most common scenario is that you use the Http service in Angular that makes XHR (Ajax) requests to the server to fetch data (not HTML).
You can use any server that is able to receive, process and response to XHR requests. Therefore PHP is as suiteable as node.js (or .NET, Java, or any other web server)
See also https://angular.io/docs/ts/latest/guide/server-communication.html
I am trying to allow users to upload images to a site I have built with Meteor, which requires a server-side route I can POST data to. Is there a way to set up a route server side such that I can call Meteor code from it (for example, a route that I can call this.userId or Meteor.userId() from)?
Server side routing is on the roadmap, but not yet available the way you need it. (At that link, Server-side rendering is set for version 1.0).
In the interim, you can do some server side rendering with Tom Coleman's excellent meteor-router mrt package. It's unclear to me how much of this will make it into Meteor core.
More likely, however, for the file upload problem, this issue describes the problem, and it looks like people have had luck implementing imgur's xhr api or perhaps even better is this smart idea.
Hope this helps.
I am admittedly a complete noob in all things server, Linux, and websockets. I finally managed to set up a VM running Apache, Tomcat, and Railo that I could connect to and serve up CFM pages, all the while learning UNIX command line navigation, server theory, etc, etc...
Here's my problem -- there is only one Railo websocket extension and it is super rinky-dink (I had to modify the CFC just to get the service to start) but I can't get a websocket connection up (I keep getting "unexpected code 200" in Google Chrome). There is minimal documentation, which is not helpful at all.
Basically, I am trying to do some prototyping for a future project that will use websockets. I like Railo for its speed, security, and excellent ability for very database heavy operations. I am interested in Node, but don't know how to get the same security and DB functionality out of Javascript as I can with CFML.
So I have a couple questions: what are my best options for WebSocket servers? Should I be trying to use Apache and/or Tomcat? People keep saying it's totally not worthwhile to have something like Node.js running the websockets portion and something else doing the heavy lifting behind it -- why is this? I'm more than happy writing WS handlers in whatever language if I can just get a nudge in the right direction, some excellent tutorials (I can't seem to find much in this department), or good feedback on how to, from the ground up, set up my Linux box to handle websockets -- and preferably how to handle both websockets and a robust language like Railo.
The Railo extension works fine for me.
What about submitting some test code so that we can debug it? Of course the websockets projects is very young and in full deployment. So feel free to fork and submit patches or suggestions.
You have plenty of options:
Railo Google Group
https://groups.google.com/forum/?fromgroups#!forum/railo
Github Extension Repository
submit a but in the Railo Jira bugtracker
The main problem of node.js is that it's mono-thread : you won't be able to do background tasks using it and local IO will block your server.
A solution I use is Go. It's very fast, has very good concurrency features and has integrated websocket and json libraries (sample : http://gary.beagledreams.com/page/go-websocket-chat.html). An efficient web application server is made in a few dozens lines of Go. You'll find that there is still much less documentation on internet than for java or even node.js through.
There are a few implementations of websockets in java but as I'm in the process of switching everything I had in java to Go I hadn't tested them. I know I use Google gson for the json encoding in java and it's very good.
The "unexpected code 200" is caused by Railo's web socket server sending an outdated response. They changed the web socket spec and Chrome uses the newer spec.
The problem seems to be caused by chrome & co implementing the new spec, "draft-ietf-hybi-thewebsocketprotocol-17". It requires the server to respond with "HTTP/1.1 101 Switching Protocols" rather than 200 OK.
The solution here would be to either update the Railo web socket extension yourself or use some other solution:
Here is a complete demo of a web socket chat server written in PHP.
http://www.flynsarmy.com/2012/02/php-websocket-chat-application-2-0/
I have used this myself to implement a real-time HTML chat served from an Arch Linux machine that I had lying around. Configuration consisted of simply setting up Apache and PHP then changing the IP address in index.html and in server.php to the external ip address of the server machine.
This flynsarmy demo includes a recent version of PHPWebSocket which is an open source web socket server written entirely in PHP and contained in a single file. The demo hooks into three callbacks: connect, message recieved, and disconnect.
The important thing to note, for me, was that the web socket protocol supports text only, not binary so while extending it for my own chat app I had to implement my own commands to help control the server. Commands in my case looked like this:
!kickusers: username, another_username, a_third_username
My server code would check the first character of all messages for a '!' and if present would treat it as a command. Then I slice up the string to get the command "kickusers" and a list of users to kick. Then I call the appropriate kick function and pass it the array of usernames.
Since my scenario was a chat client this meant that the user could literally type this command into chat and the server would accept and respond to it.
The way all this is deployed on my server is like so:
I have Apache serve the index.html page when the user goes to that location on my server in their browser. The only purpose Apache plays here is to give index.html to the client who requested it.
The index.html page contains html to display the chat and javascript to send and recieve chat to/from the server. Basically, index.html is simply a chat client written in HTML and Javascript and it runs in the browser.
I run server.php via ssh on the server to start up the WEB SOCKET server (totally separate from Apache) which just sits there and handles chat stuff like echoing text to the other connected clients etc.
Though the Arch wiki on installing Apache and PHP is specific to Arch in the way that you install the Apache and PHP packages the sections on configuring Apache and PHP apply to all. I'll save you the google query and give you the link here if you like: https://wiki.archlinux.org/index.php/LAMP
As for prototyping, the reason I gave the link to Flynsarmy's chat demo is because his comments are helpful, he wrote a blog about it, and it comes as a very simple yet complete example of how to do something with web sockets in php.