Pagination with node-themoviedb - node.js

My question is probably very simple, or the answer on it is. I'm doing some project of mine, non-profitable, movie/show tracking type web application. I'm using TMDb API, and in node I'm using node-themoviedb wrapper. Can I, somehow pass the parameters to the wrapper to which page I want from the API. Now I know, API can through URL parameters, know which page I want, but I'm asking for this wrapper. Should I even do pagination in backend, or is it simpler doing it in frontend? Thanks!

Related

How to: allow users to create their on pages on web app?

I'm relatively new to webdev, and essentially I'm trying to create functionality that allows users to create their own event pages (similar to Facebook Events, Meetup etc.).
My question is to do with the surrounding architecture of this, namely:
Given each event page will have its own url, do you need a separate file for each event in the backend?
Or is there some clever way of templating and directing traffic? (Sorry if this is vague, I'm trying to probe if there is a better way of doing this?)
I notice that most of the FB/Meetup events all have their own URLs, does this mean that they all have separate files in the backend?
I'm using Nodejs for the backend btw.
I've been Googling around but haven't been able to figure it out, I think I might be using the wrong wording... so even a point in the direction of the right wording would be much appreciated!
Thanks y'all
Generally this is handled via database-driven solutions. The "pages" are dynamic, and the URL is a parameter see #Konrad's comment that allows the pages to be looked up in a database which allows the dynamic content to be loaded into a single page which handles the complexity of each page seeming unique.

Can server side rendering in React be helpful with dynamic presentation?

My issue: For my thesis I am creating an auction site. I have an admin panel in which I would like to have some configurations so that an admin can specify that if there are 10 days before the end of an auction some components should be displayed in different ways, some should be not visible at all etc. That’s what I call dynamic presentation.
My question: Right now I am working on architecture and wondering if SSR can be helpful in any way? I am already aware that it can shorten download time of some collections from my database even by half, but I am wondering if there is any way how it can be helpful with dynamic presentation itself?
What I already know: I have read all about advantages and disadvantages of ssr or universal rendering in react. Now I am only wondering if it can be in any way helpful with dynamic presentation or it won't matter if I choose SSR or CSR.
Small side question: I don’t have the whole architecture ready yet. What I know is that I would like to have a database, one separate app for an admin, backend and frontend (either ssr or csr). My first thought on how to manage this dynamic presentation was to store some rules in the database. Then the rules could be configured in admin app should an admin want to change anything. The rules should be send to backend and calculated with some additional data from frontend. Then backend could send some flag to frontend indicating which components to display etc. In theory I could move calculating to e.g. NodeJs server should I go with SSR. What I'm wondering about is; can you think of any better way to handle dynamic presentation? What I am most afraid of is numerous ifs in the fronetend. I would like to have some more elegant solution but I have no other idea so far. For some time I thought about a scoring system but I believe it would be too complicated (instead of sending a flag, send a score and frontend will display correct things based on the score). Also it wouldn’t solve the issue of ifs on the frontend.
I am aware that on StackOverflow questions which can be answered rather than discussed are preferred but I am really stuck and would appreciate help.
Basically SSR can provide some speed on your page because all of your data will not be trying to be fetched when the react script will end with an API call. Data are fetched from database when page is requested and be passed to the component to render with the script.
Also another very basic advantage and the reason why everyone are going the SSR way is SEO. You cannot achieve SEO page with react CSR. This is because google bot etc will try and crawl your page without even render it. Is like trying to "view source" of a page. When you are in CSR the page has no content only the initial react divs empty. You need SSR to have data on the first request of the user.
SSR brings the data on the first request of the user until a reload. In the meantime react router fetches data from the api.
Let me know if that help you.
PS: also a helpful link https://medium.com/walmartlabs/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8

Is there a Polymer component that simplifies communications with MongoDB?

Given the promise Polymer and web components have in simplifying development I am wondering if anyone has developed a wrapper component that simplifies talking to a MongoDB backend? Does anyone know of one?
Is this a sane idea? I guess it would need a custom server-side piece, but even so, I expected that lots of people would have written one, but I cannot find any; or is this a case where there are so many options that I should write my own node/express/mongo server?
Or is it that the AJAX component will do all the heavy lifting and I just need to use that?
Puzzled Andy
I'm unaware of a MongoDB element, but perhaps you could use the Polymer firebase element as a reference.
https://github.com/polymer/firebase-element
I think that you should use Strongloop/Loopback (http://loopback.io/getting-started/) as backend and do ajax request thought Fetch (https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch).
Unfortunally Fetch isn't fully supported in all browser but thanks to this polyfill (https://github.com/github/fetch) you can have a full supported fallback solution.

Node.js or Express.js REST API document generator

I'm working on a restAPI using Express.js and I'm wondering if there is a way for me to generate API documents that allow a user to view API definitions or possibly even try out the API call?
What you are looking for is a good JavaScript documentation generator. I found a decent one here http://apidocjs.com/example/.
This will allow you to use just Express as OP asked.
Swagger isn't for generating docs, it's for making APIs. So you are going to need to learn a full system to get that feature.
I found a couple more here that I haven't fully looked into yet which seem promising:
Docco here JSDoc here and an article on Documentor for Node
Swagger is an amazing project for auto generating API documentation. It includes an Express module.
http://swagger.io/
https://github.com/wordnik/swagger-node-express
I found this library to be very useful when it comes to keeping your documentation and route declaration logic close together:
https://www.npmjs.com/package/swagger-jsdoc
If you use Postman while developing you might already have a Postman collection containing the most relevant calls.
If that is the case Postman has a docs feature https://learning.postman.com/docs/publishing-your-api/documenting-your-api/

Ember.js on the server

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

Resources