I want to use the spotify api to create a webapp. Without going into too much detail about the project, I want to clear up whether it would be against the terms and conditions or not.
After reading the terms and conditions, i read this line under things NOT to do: "aggregate Metadata to create data bases, or any other compilations of Metadata".
I don't plan to do any automated requests, for example, hammering the service with different queries to build a database... I'm just wondering whether I can store results from users who have performed searches via my application to the api, so that I can build content from my database on other parts of the application.
Thanks
I'm not a lawyer, so you'll need to have a lawyer confirm this (contracts, including ToS contracts, are important), but the general gist is that if you cache the results of user-generated requests to create features then you're ok. If you start caching stuff not generated by a user, you're in muddy water.
Good:
Other users who searched for "Madonna" in MyAwesomeApp also searched for "Backstreet Boys"!
Bad:
Here's a list of all the blue cover arts on Spotify: [list]
To generate the first example you can cache and work with searches explicitly done by users of your application. The second would require scraping all of the coverart in the service, which isn't allowed.
Related
I am building an ecommerce website for a project for my portfolio, and I wanted to know where the calculations should be done for the cart.
Normally I use react and I create a model folder, route folder and a controller folder but the way I was taught Angular it seems like the services acts like the routes and the actual calls to the database are done in the node server file which I am sure I could separate into a separate controller file. My question is where should the calculations for the cart be done before I send the order to the database? I thought about doing it in the cart component before the order is place or should it be done in the services or in the backend in the controller? I am just trying to figure out what is the standard
When writing an Angular app, I think it is important to adhere to the following principles that:
Components - should have a single responsibility for simple view logic only, shouldn't reach out to the server, and shouldn't do complex calculations and/or logic that is not related to the view.
Services - should have a single responsibility for (reusable/shared) and complex logic, to do outbound communication and reach out to the server, and to act as data stores (using BehaviorSubjects).
Therefore, if your calculations are needed to update the view of the cart, I would vote that these calculations need to be made at the component. If your calculations are needed to update the items or the request to be sent to the server, they need to be made at the service.
Remember, the component "shouldn't know" how the data comes to it or how it is manipulated or sent to the server. The component should only know, given any data - how to present it in the view, and shouldn't "worry about" how that data came to it. Similarly, the component shouldn't know how the data is calculated before being sent to the server, and this would fall within the responsibility of the service that works with and processes the cart data and builds the request to the server.
However, you have to always consider the security of your app, and if a malicious data modification at the client side can affect your cart. If such caculations affect the app's security - they should at least be validated at the server if not fully delegated to it.
I don't know the calculation you need exactly, but since it is an e-commerce website I assume it is simple math such as the total payment amount of checkout.
The main role of the server is communicating to the database. If a task does not involve interacting with data, you can do the calculations on the client-side. Leaving details on client-side allows you to have access to details of your formula, and reduce the communication time between client and server.
I suppose this type of topics always exist, but i like to have an specifics opinion for my case.
Since 1/2 month i'm thinking about make a listing web application for my daily life (shopping, due, etc.)
I started out define my object model like this (very simple design model)
Models image
So, i decid to create a NodeJS API for back-end, and Angular 7 for front-end. It's not a technical problem for me to develop the application and the API, but my problem is in the design of this, and particuly to the routes design.
My first suggestion for routes API is :
User :
/users
/users/:id
List :
/lists
/lists/:id
Element :
/elements
/elements/:id
Technicaly it's ok, but i'm not sure it's the good practices.
As User contains List and List contains Element, Wouldn't it be better to have routes like this :
/users/:id
/users/:id/list
/users/:id/list/:id
/users/:id/list/:id/element
/users/:id/list/:id/element/:id
Thanks for your answers, or suggestions !
PS : If you have any web sites / video / topics ... to suggests, do not hesitate.
I'd say you got it OK in the first place, the second approach is messy as you can get huge routes, and you're sending a lot unnecesary data. Why do you need the user id to get an element? An element is an entity by itself, and it will probably grow, you may need to get related elements, filter them... its better to just have /elements
What you can do is find simple relations, like:
/users/:id/lists
/lists/:id/elements
I'd recommend reading building apis you won't hate :)
Firstly you are in absolute correct path of defining Routes in angular, at the same time you have to use Lazy loading concept of Routing.
I would recommend you to, go for plural sight course , by Deborah Kurata. I'm not trying to promote or advertise anything but for your current situation that course would be the right guidance. It would provide you all the necessary things that you need to build enterprise ready apps.
Alternatively Core UI Angular provides some best designs which are already implemented with Angular Route and things. Lazy loading and other Angular routing are implemented, all you need to do is understand it.
Hope this helps.,
Principle
as short as possible
easy to read
user-friendly input when the user enters the URL
Examples
User list
/users
User detail
/user/:id
Add user
/user/new
User's functional page
/user/:id/tel
I'm relatively new to webdevelopment and have been using ArangoDB for most of that limited experience. I have a basic understanding of Node.js and creating express based CRUD apps with ArangoDB as the database.
I'm getting to a point though where I'd like to have the ability to query the database from inside the client. Say I would like to have a datalist-type element where the user types words into a searchbar. I'd like the ability to query the database from there rather than having to query the database for all of its files prior to creating the datalist. I have not found a single mention though of using database queries from the client side. I can't imagine that this is not possible. Surely when I search wikipedia through the search bar and it provides me with options I didn't just receive the entire wikipedia documents list upon loading the page? Please steer me in the right direction, I don't know how to tackle this problem.
Have a look at how to build dynamic forms, this will allow you to perform AJAX style calls from the browser window to a back end REST API service. This will allow your back end web service to gather the data for the response (from ArangoDB if required), and respond with that data, most likely in a JSON format.
Your UI can then take that response and dynamically update components in your DOM so that the user can see the data injected into the page without a page reload action taking place.
https://www.pluralsight.com/search?q=ajax is a great place to start.
Alternatively you can have a look at free content like https://www.youtube.com/watch?v=tNKD0kfel6o
I'm using Iron Router (with RouteControllers) and I'd like to know if meteor keep cache for "publishes" when page (url) change.
Example :
I want use meteor for a cooking site, so I've a section with a BIG list of recipes, and I can filter this list (by theme, preparation time, etc.). So, potentially, there will be a lot of different lists.
(This is a use case but my question can be valid for classic schema : a user visits a recipe detail page, and go away... does meteor clean cache for this subscription on server (which published the recipe datas) ?)
If I use subscriptions, does meteor keep cache when I change filter information ? And if not, how to do that without keep cache on local user database (and on server) for each request use can make ?
Sorry, I'm a beginner in meteor and it's a little confused for me. When I read documentation about meteor and publish/subscribes, I think that my app usage will increase memory excessively...
There is multiple scenarios to take into consideration:
The user closes the page and re-opens it, or refreshes.
In that case, no subscription whatsoever is natively kept.
The user changes page with a router (no reload or page closing), templates are destroyed
If the publication is done inside the router controls, it's generally cancelled (not kept) on page change. I think this is valid for both iron:router and meteorhacks:flow-router.
If the publication is done inside the template control, it is cancelled on destruction.
Else if it is done outside these pre-defined controls then the subscription is not cancelled.
You will need to adapt to these behaviours. If you want, for example, to remember the subscriptions across router pages, you will need to store them externally and control them in your own way.
afaik the cache is client-side, in minimongo. The publication on the server isn't actually used until you subscribe to it on the client. i.e.:
Meteor.publish('allRecipes',function(){
return Recipes.find();
});
Doesn't do anything by itself. A client subscription needs to refer to it.
If your collection of recipes is very large and you don't want to have a lot of network overhead to move it all to the client, then you can implement server-side search in your subscription, for example with https://atmospherejs.com/meteorhacks/search-source
Couch has a REST interface.
This means that data-updates are exclusive to PUT calls.
I'm inspecting ways to implement a humble analyics counters, and came accross the features of couchdb, sofa and couchapp - which are kin'da cool, having in mind my strong JavaScript orientation.
However, most web-analytics servcies end with making count update calls using requesting some resource, usually in an IMG or SCRIPT tag.
Is there a way I can use couchApp to
use GET request to perform my counts?
Would that be abuse of the
architecture? I mean, not everything in couch is REST - i,g, - the administration parts are not.
I'd be very happy to hear what the experts have to say :)
** Editted *
I just noted that CouchDB and Sofa are shipped with a Mochiweb web-server!
Maybe there's a way I could hook on that?
Fork or plugin idea
If you are an Erlang programmer (or you're looking for a new project to learn Erlang), then you definitely can write anything you want as a plugin/extension to CouchDB. The smallest example I know of is Die CouchDB, my proof-of-concept which adds one query that will simply stop the server.
https://github.com/iriscouch/die_couchdb
You could in principle write a plugin or fork of CouchDB to handle GET requests and do anything with them.
Note about REST architecture
I am not super familiar with analytics implementations, but the point of REST and HTTP is that GET queries have no side-effects and/or are idempotent (running 50 queries is no different from running one).
The upshot is, proxies can and will cache many GET responses, in both standard and nonstandard ways. That seems incompatible with user tracking and data gathering techniques; however maybe analytics tools still think the benefits outweigh the costs.
For most people, it's probably easier to use external tools.
Log idea
One trick is to GET anything from Couch, and then check the log entry from couch. You can get the couch log by querying /_log as the admin. The log will show users' IP address, request path, and any query parameters.
For example
$ curl -X GET http://localhost:5984/?userid=abcde\&windowsize=1024x768\&color=blue
{"couchdb":"Welcome","version":"1.1.0"}
$ curl localhost:5984/_log | grep userid
[Mon, 23 May 2011 00:34:54 GMT] [info] [<0.1409.0>] 127.0.0.1 - - 'GET' /?userid=abcde&windowsize=1024x768&color=blue 200
Next you can process that log entry and re-insert into your actual analytics database yourself.
Wrapper idea
A final solution is to run a simple reverse-proxy which converts your GET requests into whatever you need. NodeJS is getting popular for tasks like that, but you can use any web platform you prefer: PHP, ASP, JSP, whatever you know already.
You simply respond to the GET request and do whatever you need on the server side, such as inserting the relavant information into your analytics db.
Good luck!