New answers tagged

1

Also, don't be afraid tot tell me it's a silly idea. It's a silly idea :P And here's why: Data caps. The primary hog when it comes to data are things that happen in the background without any user's consent. You wouldn't want to be leeching off a person's data. Battery and heat. Of course, processing takes up resources and resources doesn't come free, ...


2

It's certainly being done, but I think whether it's a good idea depends on the style and size of application. How big is this application and how long will it live? It's harder to trace behavior and refactor with a very long path of code that might rely on the object-properties and relationships, meaning it has to be inspected and fixed as a unit. (As ...


0

I would propose a more objective basis. Go to your existing HTTP logs. Assuming this is an update to an already in the field app, simply pull the logs and examine the HTTP requests which are included. This provides an absolute objective basis fore your load modeling instead of a wetted finger in the air to test the wind. Also, keep in mind from a QA ...


0

If you want to partition the data by school/client, you'll probably want to look at schemas instead of views. A schema will put the tables (and indexes, triggers, etc) in a separate namespace. Depending on the database you use, you may be able to put individual schemas in separate files, which should give you the ability to put individual schools/clients on ...


1

Views will not help with performance; they are effectively just queries with a Name. Indeed, they may actually make things worse and, IIRC, MySQL does suffer from this "View overhead". Indexes are what you're looking for. Sensible indexing can make millions of rows just as responsive as a handful of them. Don't get carried away, though. Whilst ...


2

It's pretty clear that the main difference, all other things being equal, is related to the number of HTTP requests. For example if your server-generated page uses the right cache control headers and best practices for all of the static assets, then a page navigation will only result in a single http request. It can be very very fast. If your SPA issues ...


1

I would like to add a different point of view. Lets say we have a product (desktop app, webapp, doesn't matter) that use logs to trace its activity. It does also with errors bc "it's a good product" and errors have been designed with codes (lets say like Oracle does). Such logs/traces were thought to be read by user instead of developers. Product also ...


4

When developers talk about "logs", they're most often referring to plain text files containing information that is meaningless outside the context of the specific code that logged them and has no intended purpose other than troubleshooting that code when something goes wrong. When developers talk about "internationalization", they most often mean "when the ...


2

Handling errors consistently Errors can take the form of a thrown exception, a proper Error object, a plain object, an optional argument to a callback, a Promise, a special return value, a simple string, etc. At some point, all of these have to be converted into some message for the user. How do you convert between all the various forms, where does this ...


2

If I'm following correctly you are considering using an API that only provides a dumb interface into your data, ie you can't query through the API you can only request all the data in one go. So if you want to look up the Product for one user you have to fetch all, lets say, 20 million products and on the client side filter through them for the ones that ...


3

If you want to ease load on your servers where the webservices providing REST endpoints live, there is no other way than to introduce caching to these servers. You could specify a constraint that a client would have to introduce cache in his application so he does not hit your services that often, but how are you going to guarantee that is really going to ...


1

You said: Now, the difficulty is: each time we would have to know about a user products, we would need to send a request to the API to get the products names and other data, since we would only save its Id internally. This is okay in this simple example, but there will be cases much more complex than this (Reports, for instance) and it just ...


0

For middleware I would put a bus in order to concentrate all the possible sources of data and offer a single interface of access. Such interface will provide VC facades. You can also implement your own bus service. And the solution of Repos already exposed could fit very well under such bus "layer/service" For View layer, as you pointed its mandatory to ...


0

I prefer using Repository Design pattern with large application, you can create repo classes that responsible for fetch data from Web Services and cached it with anyway you prefer. I prefer using abstract Factory For Web Services and its configuration Classes which will give me extensibility to switch to new service or upgrade configurations. also i will ...



Top 50 recent answers are included