I have built a node.js app for which i would like to realize "snippets" to be included in external web applications. It means that i must create some javascript scripts to be included and called from external apps that call a node.js view and its scripts/css .
Does node.js provide a way to do it natively or do i have to create the script that embeds the view and the related client libraries?
enable cross-origin resource sharing:
Cross-Origin Resource Sharing (CORS) is a specification that enables truly open access across domain-boundaries. If you serve public content, please consider using CORS to open it up for universal JavaScript/browser access.
Must read: http://enable-cors.org/#how-expressJS
Important stuff:
Access-Control-Allow-Origin
Access-Control-Allow-Headers
Sounds like components might be your answer:
https://github.com/component/component
http://tjholowaychuk.com/post/27984551477/components
I hope I understand your question - You want to display an html-like snippet on a different site.
One way of doing it is to provide an API, but it will probably be a
JSON API, and the other site will have to display it on its own
(somebody already noted CORS is needed for this). You could just serve a JSON with html in it (though you need to make sure the other app doesn't escape it)
You could have your server serve an image (like they do in travis CI), but then the other site will show it as an image (copy paste the text won't be possible)
You could use Iframe, serving an html to this other site.
There's the possibility you meant something totally different, like reusing your server an client code - in that case I recommend http://browserify.org, or the already mentioned component.js.
Related
I have a rest-api that I will use to render html using some basic templating language. I wonder if there is any good platform or service for pre-rendering HTML-files and serv them statically. For performance and scalability.
I need to pre render the pages contiously, like every 24 hours, and it should also be possible to tell the system to re-render a specific page somehow. I'm comfortable in most open-source languages, node is a favourite.
It seems to me that the most straightforward way to accomplish this is to use two tiers: a rendering server and a cache server. When cache server starts up it would crawl through every url on the rendering server and store the pre-rendered HTMLS files into its local directory. For simplicity you can mirror the "directory structure" and make the resource paths identical. In other words, for every URL on the rendering server that looks like this:
http://render.xyz/path/to/resource
You create a directory structure /path/to on the cache server and put a file resource in it.
Your end-users don't need to be aware of this architecture. They make requests to the cache server like this:
http://cache.xyz/path/to/resource
The cache server gives them the result they are looking for.
There are many ways to tell the cache server to refresh (re-generate) a page. You could add a "hidden" directory, let's call it .cache-command, and use it to handle refresh requests. For example, to tell the cache server to refresh a resource, you would use a URL like this:
http://cache.xyz/.cache-command/refresh/path/to/resource
When the cache server received that request, it would refresh the resource.
One of the advantages of this approach is that your cache server can be completely independent of the render server. They could be written in different languages, running on different hardware, or they could be part of the same nodejs application. Whatever works best for you.
I developed a small node.js app in which I can configure conditions for a custom javascript file, which can be embedded in a webpage, and which modifies the DOM of that page in the browser on load. The configuration values are stored in MongoDB. (For sake of argument: add class "A" to DOM element with ID "B" )
I have difficulties to figure out the best way to serve requests / the JavaScript file.
Option 1 and my current implementation is:
I save a configuration in the node app and a distinct JavaScript
file is created for that configuration.
The page references that file which is hosted and served by the server.
Option 2 and where I think I want and should go is:
I saves a configuration (mongodb) NO JavaScript file is created Pages
a generic JavaScript link (for instance: api.service.com/javascript.js)
Node.js / Express app processes the request, and
returns a custom JavaScript (file?) with the correct values as saved in mongodb for that configuration
Now, while I believe this is the right way to go about it, I am unsure HOW to go about it. Any ideas and advise are very welcome!
Ps: For instance I wonder how best to authenticate or identify the origin, user and requested configuration. Shall I do this like: api.service.com/javascript.js&id="userID" - is that good practice?
Why not serve up a generic Javascript file which can take a customized json object (directly from mongodb) and apply the necessary actions? You can include the json data on the page if you really need to have everything embedded, but breaking up configuration and code is the most maintainable approach.
I have a few private apis written in plain old express. Time to let it out and provide some api documentation.
What I don't want (at least yet) it to re-write my express app to integrate api documentation into the code. Mainly since I am not sure what framework or spec to use to document my api I don't really want to be locking into one particular thing.
I would like to serve out the doc as part of a sub resource under my api (ie I do not want to run a different server or subdomain). Maybe '/api/docs'. A plus would also be a UI that I could embed within my app that could parse the docs and at the very least provide a nice presentation of the docs in html (api interaction is a plus).
Things like swagger-node are cool, but would require me to re-write all my express code to integrate swagger. At that point I have a big investment and am tightly coupled to swagger.
Is there a way to serve out swagger or iodocs or maybe something else to document my api in a way that is minimally invasive to existing routes?
EDIT:
I could serve out the Swagger spec from a hand written doc. Problem I see is that you have to define basePath in the swagger doc. This does not really allow me to easily deploy under different domains.
There's a wide array of node.js tools to integrate Swagger with your application, and I assume they offer different ways of doing so. You can find a list of such integrations here - https://github.com/webron/swagger-spec/#nodejs - but I can tell you that there are additional tools out there that are not listed there. You can try searching github for swagger and node/express.
As for the manual spec and the basePath - Swagger 2.0 actually solves that for you. You can use the online editor - http://editor.swagger.io - to write your specs in a more human-friendly YAML form, which then you can export to JSON.
Unlike Swagger 1.2 and previous versions, the basePath is now split into three properties - schemes (http, https), host (domain, port) and basePath (the root context of the application). None of these properties are mandatory, and they all default to whatever is serving the swagger.json file (the spec itself). schemes defaults to the scheme service the swagger.json, host defaults to the host used for serving the swagger.json and basePath will be \ unless explicitly specified. I believe this should solve your concerns regarding the basePath.
I've been using ember, node, express since 2 months ago.
I've developed an small app, now it's time to add user auth to it but I can't figure out how to do this.
There are a few questions I have:
1.- In SPA apps, where there's only index.html, I include all .js ember files. So, the user could be able to see all the app logic without auth?. How can I add the libs only when the user has been auth?
2.- What's the right way to auth in ember? I haven't seen a solution in official documentation.
3.- How the frontend communicates with the backend, what's the logic here? It's in every route?
Also I'm looking for an example or tutorial.
Thanks you!
I believe these videos target exactly your question
http://www.embercasts.com/episodes/client-side-authentication-part-1
http://www.embercasts.com/episodes/client-side-authentication-part-2
just to mention a great resource for ember tutorials http://emberwatch.com/ - it contains screencasts, books, talks.. articles - all you need to get started.
There is nothing bad about "seeing logic", you are protecting data, not code. Still, if you really want to protect your code, you can create a separate login page and require authentication for every other resource (app html, styles, scripts, etc.). But protecting EVERY resource of your app means that you can't delegate handling static files to nginx or cdn or whatnot. So, think carefully.
There are to approaches: embedded authentication and separate login page. For the first one you can use https://github.com/Vestorly/torii or https://github.com/simplabs/ember-simple-auth. If you decide to go with the second, you can just use authentication provided by your backend (passport.js, etc) and redirect to login page on failures.
Nothing special, you just write your model methods and handle possible authorisation errors. You might also want to have a user object around to use in your template and route logic.
I'm developing a very dynamic web application via ember.js. The client-side communicates with a server-side JSON API. A user can make various choices and see diced & filtered data from all kinds of perspectives, where all of this data is brought from said API.
Thing is, I also need to generate static pages (that Google can understand) from the same data. These static pages represent pre-defined views and don't allow much interaction; they are meant to serve as landing pages for users arriving from search engines.
Naturally, I'd like to reuse as much as I can from my dynamic web application to generate these static pages, so the natural direction I thought of going for is implementing a server-side module to render these pages which would reuse as much as possible of my Ember.js views & code.
However - I can't find any material on that. Ember's docs say "Although it is possible to use Ember.js on the server side, that is beyond the scope of this guide."
Can anyone point out what would be possible to reuse on the server-end, and best practices for designing the app in a way to enable maximal such reuse?
Of course, if you think my thinking here doesn't make sense, I'd be glad to hear this (and why) too :-)
Thanks!
C.
Handlebars - Ember's templating engine - does run on the server (at least under Node.js). I've used it in my own projects.
When serving an HTTP request for a page, you could quite possibly use your existing templates: pull the relevant data from the DB, massage it into a JSON object, feed it to handlebars along with the right template, then send the result to the client.
Have a look at http://phantomjs.org/
You could use it to render the pages on the server and return a plain html version.
You have to make it follow googles ajax crawling guides: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started