@vwp/commerce-gallery v1.0.2

v1.0.0

Primeira verrsão do FileManager para o Viewup Commerce.

Inicialmente o usuário devará passar, como construtor da classe FileHelper, o objectId da empresa para qual ele está fazendo o upload. Assim configurado, o metodo upload (de FileHelper) poderá ser chamado passando um array com a localização do arquivo no computador ou uma url válida, sendo que, no segundo caso, a imagem será baixada e repassada ao Viewup Commerce.

Assim que concluido, o FileHelp retornará uma promise com um objeto que contem {error: Primeiro Erro encontrado,erros:Todos os errors durante o processamento, items: Objeto com os dados dos arquivos processados (_id,file_name, file_hash, ...) } O usuário poderá usar esses dados para associar uma imagem a um produto, categoria ou marca.

Exemplo:

execute: 
npm test

Para ver o funcionamento por dentro, consulte o arquivo teste.js

Mistake #1: Blocking the event loop

JavaScript in Node.js (just like in the browser) provides a single threaded environment. This means that no two parts of your application run in parallel; instead, concurrency is achieved through the handling of I/O bound operations asynchronously. For example, a request from Node.js to the database engine to fetch some document is what allows Node.js to focus on some other part of the application:

// Trying to fetch an user object from the database. Node.js is free to run other parts of the code from the moment this function is invoked.. db.User.get(userId, function(err, user) { // .. until the moment the user object has been retrieved here }) node.js single threaded environment

However, a piece of CPU-bound code in a Node.js instance with thousands of clients connected is all it takes to block the event loop, making all the clients wait. CPU-bound codes include attempting to sort a large array, running an extremely long loop, and so on. For example:

function sortUsersByAge(users) { users.sort(function(a, b) { return a.age < b.age ? -1 : 1 }) } Invoking this “sortUsersByAge” function may be fine if run on a small “users” array, but with a large array, it will have a horrible impact on the overall performance. If this is something that absolutely must be done, and you are certain that there will be nothing else waiting on the event loop (for example, if this was part of a command-line tool that you are building with Node.js, and it wouldn’t matter if the entire thing ran synchronously), then this may not be an issue. However, in a Node.js server instance trying to serve thousands of users at a time, such a pattern can prove fatal.

If this array of users was being retrieved from the database, the ideal solution would be to fetch it already sorted directly from the database. If the event loop was being blocked by a loop written to compute the sum of a long history of financial transaction data, it could be deferred to some external worker/queue setup to avoid hogging the event loop.

As you can see, there is no silver-bullet solution to this kind of Node.js problem, rather each case needs to be addressed individually. The fundamental idea is to not do CPU intensive work within the front facing Node.js instances - the ones clients connect to concurrently.