201

Perfect is the enemy of good. Or put another way, don't worry about it today. If your app does what it needs to do, then it's fine. It's not a bad thing to rewrite parts of software further down the line; by that point you 1) know more clearly what you're trying to build and 2) know which bits are actually the bottleneck. You could spend an enormous amount ...


200

You can't, and the more people understand this, and the deeper they understand, the better for the world. Code that runs on a device under the user's control cannot be controlled. Smartphones can be jailbroken. Set-top boxes can be cracked. Ordinary browsers don't even attempt to prevent access to JavaScript code. If you have something worth stealing or ...


190

You might not enter random values into fields of a web application, but there certainly people out there that do just that. Some people enter random by accident and others do it intentionally trying to break the application. In both cases, you don't want the application to crash or exhibit other unwanted behavior. For the first type of user, you don't want ...


175

In HTTP 1.1, there actually is a status code (307) which indicates that the request should be repeated using the same method and post data. As others have said, there is a potential for misuse here which may be why many frameworks stick to 301 and 302 in their abstractions. However, with proper understanding and responsible usage, you should be able to ...


132

Data is King I think its a bit unreasonable to expect a web application circa 2013 to be still up and runnable in 2053. Technologies are going to change. Platforms are going to come and go. HTML may be a quaint memory by then. But your data will still be around. So data is your primary focus. As long as your data is still there, people will be able ...


109

Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable? The crux of the issue isn't scalability. The crux of the issue is thinking that you will get it right the first time. You should focus on writing clean code. Because clean code maximizes convenience when you (inevitably) have to change something in the future. And ...


102

Never Assume Anything You cannot assume that any user will not do something "dumb" with your software by accident or on-purpose. Users can accidentally press the wrong button, the cat can walk over the keyboard, the system can malfunction, their computer can be hijacked by malicious software, etc. Furthermore, the user themselves may be malicious, ...


92

"web applications should be stateless" should be understood as "web applications should be stateless unless there is a very good reason to have state". A "shopping cart" is a stateful feature by design, and denying that is quite counter-productive. The whole point of the shopping cart pattern is to preserve the state of the application between requests. An ...


89

Let's talk about cars. Oh wait, we already did - remember that time we met, some time ago? We talked about cars. In fact, you seemed to be quite the expert on cars. You were able to explain, in detail, all of what's right, wrong, and exciting about the latest Formula 1 race. You knew by heart all of Lamborghini's models, including their price and ...


79

An ideal ReSTful service allows clients (which may not be in-browser) to perform any needed task in one request; because the full state needed to do that is held by the client, not the server. Since the client has full control of the state, it can create the state on its own (if that is legitimate), and only talk to the API to "get 'er done". Requiring ...


72

In its most basic form, a website serves static files. Mapping the URL path to a file path is the most obvious choice; essentially, it's a read-only FTP site. Then people wanted to change the content of the page with some scripting. The easiest way is to embed a scripting language into the page and run it through an interpreter. Again, given the already ...


69

The rule here is: Do everything client-side that doesn't affect anyone else if the user tampers with it. In particular, that means graphical effects. Do everything server-side that needs to be secure, and just send UI events from the client (eg. then client just says "the user tapped the Buy button" while the server actually carries out the transaction). ...


60

Generally the DAO is as light as possible and exists solely to provide a connection to the DB, sometimes abstracted so different DB backends can be used. The service layer is there to provide logic to operate on the data sent to and from the DAO and the client. Very often these 2 pieces will be bundled together into the same module, and occasionally into ...


60

Plenty of sensitive information gets stored in databases. In fact, a central database is probably the most secure way to store this data. Large enterprise databases have tons of functionality to do things like encrypt sensitive information, to audit who accesses it, to limit or prevent people including DBAs from viewing the data, etc. You can have ...


60

There are several factors to take in account. To illustrate those points, I'll use an example of a field where a user should enter a percentage in a context of a quota defined for a specific task in terms of how much disk space the task could use. 0% means the task wouldn't be able to write anything to disk; 100% means the task could fill all the disk space. ...


56

It's true that web applications should be stateless. However, session variables, cookies, and tokens don't violate this when they are all stored on the client (web browser). They can be parameters in the request. Here's a simplified model: Web Browser (has state) <-> Web Server (stateless) <-> Database (has state) This could work for Software ...


54

In theory, the pros and cons are as so: Pros: One place to contain all of the business logic Possibly faster applications because multiple SQL queries and such can be performed in one "round trip" to the database Trivial to make use of the stored procedures from multiple applications Cons: A DBA will be required for performance tuning All developers ...


53

@FrustratedWithFormsDesigner hinted at this above, I'll be more blunt: you've been charged with a expensive but useless task. I suspect the CEO is looking for irrefutable, objective evidence which will support his choice of language. The problem is that preference of language is loaded with far too many subjective and extrinsic factors for the white-paper ...


52

Though they have their own internal IT team, they have asked me on what will be the hardware requirements for the live servers eg. RAM, 32 bit or 64 bit. Perhaps they figure that as the developer, you have more insight into the app's requirements than they do. You've presumably been running the application and know how much memory it requires under ...


47

I found a good explanation on this page here. The simplest situations on the WWW are "idempotent" transactions, i.e those which can be repeated without causing any harm. These are typically "GET" transactions, either because they are retrieval of straightforward URL references (e.g href= or src= attributes in HTML), or because they are form ...


40

We produce software that has been in use by paying customers for over 20 years. The codebase has outlasted several generations of source control tools. Our software hits all your bullet points except for the tablet thing. Some of the concerns include ESIGN and UETA. Our lawyers believe that we need to keep electronic records readable for a minimum of 10 ...


39

I am the writer of post in question. I have got my fair share of working on different technologies and different architectures. Based on above, I can safely say that having service layer and dao layer is always a good idea. DAO should be limited to only add/update/insert/select Entity objects into/from database and that's all. If you want to do anything ...


39

You can look to a white paper by Roy Fielding on REpresentational State Transfer (REST) as to the when and the why. The first framework I was aware of that made the distinction between a resource and a file was Ruby on Rails--introducing the concept of URL to code routing. The main concepts behind REST that were transformational were: A URL represents a ...


38

You need to back up a couple steps and, in consultation with your client, work out a threat model. (Yes, that's a link to a 600-page book; yes, I am seriously recommending you read the entire thing.) A threat model starts by asking questions like Why does the app need to store this sensitive data in the first place? Can you avoid storing it at all? Can ...


38

XSLT does not really have a useful role in the modern interactive web. The purpose of XSLT is to transform from one XML language into another - but you actually never need to do that in the first place. How powerful, fast and well supported a technology is is irrelevant if you don't have the problem which the technology is designed to solve. There are ...


35

You literally cannot prevent users from accessing and modifying content that you are sending them. You have no control over the browser, or which browser they use, or whether they are in fact downloading your source code via a browser. You are executing your code on another person's device. You should not and cannot assume anything about the integrity of ...


34

You don't have to learn JavaScript and HTML to create web applications. But you will. If you really want to write webapps in mostly Java, have a look at the Google Web Toolkit, which does vast amounts of Java to JS, and can satisfy a good chunk of the code needed for a webapp. Django is a similar framework for Python. And if you really want to avoid ...


33

As always, such decisions involve a trade-off between different goals, some of which conflict with each other. Efficiency would suggest that you perform calculations in the front-end - both because that way the user's computer uses more power and your server uses less, and because the user sees faster feedback, which improves the user experience. Security ...


33

REST was designed for the web, and the web was designed for REST. The two just fit will together. Roy Fielding's 2000 PhD thesis Architectural Styles and the Design of Network-based Software Architectures defined and introduced the term REST, and there is significant interplay between the web and REST: Roy Fielding worked on HTTP/1.1, of which he is the ...


32

First of all, it's your job if the project manager tells you so. Smaller companies often don't have full-time DB experts. There isn't (and shouldn't be) a clear distinction between developers and DB experts anyway - any good developer will have considerable knowledge about DBs, and any good DBA will know how to code, at least in the DB's language for stored ...


Only top voted, non community-wiki answers of a minimum length are eligible