When starting a web app project at minimum what should be taken into consideration from the point of view of security, scalability and maintainability so that there is minimum disruption as the project grows?
From a security perspective, the OWASP top 10 is required reading if you don’t know it yet. More generally, always assume your users are hostile and don’t trust any input that comes from them (this may come across as harsh, but really: if there is a loophole or data that you don’t validate server-side, someone will abuse it).
If you need to support a variety of clients, especially older ones, stay away from fancy js stuff and focus on vanilla html and server-side rendering. Invest in a way to test your website from different clients (this can just be a few VMs running different OS/browser versions). Fun story: after launching a new SPA website, extensively tested in Chrome, FF and Safari, our first user complained of seeing a blank page. He was using IE11...
Scalability is pretty much a solved problem for websites: load balancing and auto-scaling will take you a long way; you may eventually encounter a bottleneck at the database layer for which mature solutions (e.g. read replicas) exist.
Invest in monitoring your app, both from a technical standpoint (response time, % of 4xx/500 pages, etc) and from a functional perspective (e.g. set up a script that simulates a login, fetching a document, filling out a form... and send an alert if the script fails)
As for security, as laurentl suggested the OWASP is a good starting point. From there look at all related security requirements of the country your project/product will be subjected to.
For scalability, pick a good database and get really familiar with the short comings of it (no design is 100% perfect). Also, check out the language/runtime for your project uses for scaling and what real world solutions others found effective (real-world is what counts on this one).
For maintainability, look at the support pledge for each library, framework, middleware, etc. used in your product. Sticking with what is supported and what your clients can do is important. If a lib/framework/tool is going to be unsupported then that is going to cost you (either refactor a replacement or get ready for legacy). Maintenance is going to be an ongoing cost for any product and picking long term supported technology is key. I personally restarted my own project 3 times because of how fast support waned for the versions of technologies I was using.
Another thing to consider is the future of your project. Every three to six months a genuine look at the product/project and the real world market needs.
How long the customer expects the web service to properly function:
The shorter the time - the more canned stuff you can probably integrate into a solution.
The longer the time - less reliance on external dependencies.
Security - as much as you can, use common sense and current best practices. If there are data laws/financial concerns regarding it's function, then you will need to follow any requirements of those.
> Security - as much as you can, use common sense and current best practices.
Please could you share any links to current best practices? In some of the previous comments OWASP was mentioned, apart from that are there any other resources to follow for web app security?
I don't know what your platform is - if you search for your code/db environment and best practices you will find some insight, read a few and determine what makes sense.
Generally you don't trust any input, filter anything whether it is a page link or a form field, be mindful of what you put in your database and what you serve back will not cause any problems - how external input communicates to the outside world (HTML, PDF, email, links, etc.)
Get as much of your code below web root. Use SSL. Setup regular backup and test it. Keep your code environment updated (but not bleeding edge - too new can be vulnerable too)
A 'right' answer for this will always vary based on the project goal, MVP (Minimum Viable Product), and development workflow that you want to follow. If you provide more context, it may result in suggestions with a better scope instead of comments that suggest random libraries and development strategies.
Well, I am not a web developer; thought I have developed simple web apps for understanding the development process but never deployed anything in the wild. My experience is into embedded and desktop application development. I recently received a request from one of my clients to develop a small web app that has to be accessible from the client's multiple offices with 3K employees. The employees use varying devices and web browsers (e.g. IE8+, old Android and iOS phones etc). I am looking for information on what things I should look for, from deployment, security and maintanibility point of view, before, during and after deploying the software. The web app is a simple work log book where employees log in the tasks done everyday and supervisors audit the information entered.
I want this web app to be secure, scalable and maintainable. If the client in future wants someone else to take over the project then it has to be easy for them to do so.
If you need to support a variety of clients, especially older ones, stay away from fancy js stuff and focus on vanilla html and server-side rendering. Invest in a way to test your website from different clients (this can just be a few VMs running different OS/browser versions). Fun story: after launching a new SPA website, extensively tested in Chrome, FF and Safari, our first user complained of seeing a blank page. He was using IE11...
Scalability is pretty much a solved problem for websites: load balancing and auto-scaling will take you a long way; you may eventually encounter a bottleneck at the database layer for which mature solutions (e.g. read replicas) exist.
Invest in monitoring your app, both from a technical standpoint (response time, % of 4xx/500 pages, etc) and from a functional perspective (e.g. set up a script that simulates a login, fetching a document, filling out a form... and send an alert if the script fails)