Where do you start your programming for a web app?

Question

I have a great idea for a new web app. I have it all planned out of what features are needed, what files and what language I'm going to use. All the creative thinking is out of the way and now I can sit down and focus on my code.

However, I can never really find a foothold as to where to start. Should I start with the installation file? How about the main page? Or what about the admin interface?

I guess the question is, Where do you start programming a new web app? Whether it be the settings page, admin interface, main page, or installation, what file do you work on first?

Answer 1

Maybe I'm weird, but for basically everything I write (web app or not) I start with a data/object model and go from there. Saves me a lot of trouble later on.

Answer 2

I've been doing this professionally for many years now and what works well for me is to begin with a page flow for the website first, from a user's perspective. This will make it clear in your mind what then end result will be.

Then you can start to identify domain objects and rules for each page, and from there begin to model each use case or "interaction" the user has with a page. Like a button click or text entry, etc. From the interaction comes more domain objects and ultimately some database tables to support the objects and data that needs to be stored in the system.

That's it in a nutshell, depending on your preferred development language there are likely many walkthroughs or tutorials to help with the construction phase.

Answer 3

Since I work with the Django framework, the first place I generally start is the models/database structure.

Defining my data structures first helps me get the foundation right, before I go implementing things I might have to re-work if I change my mind about how a data structure should work.

This obviously is going to be more relevant for a data-driven type of site, but all sites are going to be data driven to one degree or another. Ocassionally user workflows are a good place to start, but more often than not, I find myself doing the data structures anyway when I try to start with that.

Answer 4

With a pencil and paper.

• draw up a list of every interaction your users will want to do on your site.
• Next sketch out all of the web pages you will need to support each one of those interactions.
• Draw a graph of how each of those pages link to and interact with each other.
• Note down what information the server must keep track of to support those interactions.
• Sketch out the structure of each of those data items, Be sure that no information is missing, and most importantly, no information is duplicated
• Take a moment to see if there's anything in any of the notes you've just made that are actually superfluous, and scratch them out.
• Form a nice list of each feature you need to implement, and put it in order of most critical and hardest at the top to easiest an least noticeable at the bottom.
• Turn on your computer.

Okay, actually I'll admit I do most of this in digital form. Evernote is nice.

Everyone seems to be telling you to start with your data. They're right, of course. You can use your framework of choice, but build models that persist data and try to interact with that data in a console. with django you can do that using ./manage.py console, rails is scripts/console. Another way of approaching it is to write unit tests that exercise the desired functionality of the models. Run the test and see that your test fails, then go implement the models and check that the tests work now.

Answer 5

Here is my advice. Throughout this lengthy advice I will refer to an example application that illustrates how you can build your system:

Let's say you're building a website that lets people maintain to-do lists for themselves. Let's say you expect it to be sophisticated, with interesting features and details and capabilities.

Do the following:

Capture your high-level requirements

• Decide on your first deliverable, one that will implement a simple but (somewhat) useful and testable subset of the functionality you dream of for your site. Write it down as one or more brief and simple descriptions of how users will interact with your system, and what it will do for them - something like this:

  A user comes to the website and signs up for an account. She then logs in and sees a to-do list, with a single example to-do item to get her started. Then she enters her own to-do item - "Call my mom", and puts a date on it - two days from the current day. One day later, she logs in and sees both the example and her actual to-do item on her list. Two days later she logs in and sees the same list, but her item is marked as "overdue". She then clicks on her item and marks it completed. When she returns to her to-do list, it's marked as "completed".

• Maybe you cut it down so that in the first deliverable there is no example item, and she doesn't update the to-do item. Or maybe not.

• If integration with other systems is a big part of what you need to do for your product to be successful, your deliverable should include scenarios that describe the integration:

  After the user adds a new task, it sends a message to the 'Remember The Milk' site with the user's credentials and relevant fields from the task. After each update to a task, it updates RTM.

Specify your architecture

• Decide on some architectural choices for your first deliverable: what server technology you will use; what language; what host(s) you will use during development; whether the site will be all AJAX-y and stuff, or more plain; what db to use; what open-source libraries you will use; your source control system.

  You're going to build a snazzy AJAX site using JSF/Facelets, JBoss RichFaces and Java, and deploy it on Tomcat. You'll use MySQL to store user data, and run all of that on EC2 machines. Your application will incorporate Hibernate for data access. You'll put your code in Git.

Design the interfaces

• Now design, on paper, very simple pages that illustrate how your website will look after the first deliverable is completed. Perhaps you'll have a home page, a registration page, a to-do list page, and a to-do item page. Or maybe you'll call them "views", and implement it with AJAX so it's all kind of one page.

  Sorry, I'm going to pass on the mockups, but imagine some pictures here: one for each view - home page, registration, to-do list, to-do item.

• If your site has integration requirements - i.e. if part of your first deliverable involves using a particular web service - spend a little time researching the integration technique you will use, and be clear on what messages you have to send/receive, and when. It wouldn't hurt to write up a paragraph or two.

  You note that you will make web service calls that have the subject name, the user name, a date, and a completion status; you note the specific REST verbs you'll use, and when.

A bit of planning

• Do you have all the stuff you specified in the architecture - server instances, a source control system, and are they ready to go? Can you check into source control? Can you start the server? Are you reasonably familiar with all the technologies you have to use? Do you have some time now?

• Yes? That's awesome! You've now got three of the four things you need to start coding your system: some requirements to solve; an architecture and its components; the design for how your system will interact with the world. All you need is a little bit of a plan now.

• Each sentence in your description is roughly a development task in your plan. Most of them present the user with an interface and accepting input. Decide, or at least theorize, on an order in which you will execute each of these development tasks. You might want to write that down. You might even want to make some time estimates. Hey, it's your life, I don't know. If you have a stakeholder - someone who isn't you - you'll definitely want to write down that plan and make those estimates.

  Task 1: implement the to-do list page. half a day. Task 2: implement the to-do item page. half a day. Task 3: migrate from in-memory data to MySQL. a day. Task 4: implement registration. a day. etc. Is it really worth it to plan to do something in half a day? I don't know. Maybe you can do all that in a day - if you're familiar with all the technologies, you probably can. (And yes, Rails will let you go faster, but not that freaking much faster, I think. I've built a small site in it, kept it up for several years, but I'm not convinced it's really that big a time-saver.)

Write some code

• Build your first page/view/whatever. Mock it up using your chosen technology. Deploy it to your server. Start the server. Fetch the page. Is it there? Awesome. If not, fix your server configuration until it's there.

  Example: build a JSF/Facelet page that has just a page tag and some boilerplate HTML that displays a fake to-do list. Write your web.xml, JSF, and facelets config files so you can fetch the page. Build a web app with all those artifacts, deploy it to Tomcat. Start Tomcat. Point your browser at the page, and see if it looks like you expected. Does it? Not yet? Fix it. Now? Great! Check it all into Git.

• Now you should make your page do something useful. Replace some of the boilerplate in your page/view/whatever with references to code - objects that represent what you need.

• For data access, I recommend you write an interface that defines "finder" methods that return instances of the objects you need, and for starts, that you implement the interface in memory. Your first pass might just have objects declared in source, and return those when asked. Later you can use a real database schema.

  Put some field tags in your to-do list page, replacing the boilerplate. Reference a service bean in your page, and iterate through a list of Todo objects that you get from the bean when you call TodoService.findTodo(). For each todo, display the subject, the scheduled date, and the status. Write a Todo class with getter methods. Write a TodoService class and give it a findTodo method. Have it return a bunch of Todo objects that you define right there in the class, just for the moment.

• Deploy your updated page and code to Tomcat. Fetch the page. When it looks right, awesome! You can go to the next step.

• Personally, I might implement a Todo item page next, before I started actually persistent data in a database. But either way, you're going to do that soon. Now you should create a schema file, and use it to create an instance on your database server. (Or whatever is analogous; perhaps you're using Amazon SimpleDB.). Then you build another implementation of your service (or perhaps another implementation of a data access object) that reads and writes to the database.

  Use Hibernate's schema generation tools to create a schema file. Create a database from it on MySQL. (Consider adopting a schema evolution tool.) Write a TodoDAO object that gets a Hibernate session and calls a finder method, returning the results.

Program like an engineer: write unit tests and practice test-driven development

• When you need to write a method that isn't just a dumb getter, setter, or call to an external library, write a unit test first. Read up on test-driven development if you haven't already. Do it. Not slavishly, but be generous in when you write tests. If you really care about the app, you will thank yourself later.

  You've implemented enough to allow users to register, view todo lists, and enter todo items. Now you want to put a button on the todo list page that toggles the display of completed items on and off. Your service method that fetches the user's todo list should check the state of the toggle and display the appropriate set of todos. Before you modify your service method, write a unit test for it that verifies that it returns the data it gets from the data access object; use a mock data access object to supply Todo objects. Now write another test that sets the toggle so that completed items aren't displayed, has the mock data access object return both completed and uncompleted items, and verifies that the service returns only uncompleted items. Run it. It should fail. Now modify the service method. Run the test. When it succeeds, you might want to check in your code.

And so on...

Now you're on your way; keep implementing those tasks; keep writing tests; keep checking in code; deploy all the time; show it to people whenever you can; use it yourself whenever you can. You're going to kick ass.

Answer 6

I tend to think of the back end logic and associated datastructures/database tables that are going to be needed. I code those and if appropriate a REST interface. Then I tackle setting up the templates for the pages. But I always try to think of what it needs to accomplish the required key tasks, and build up those methods first.

Answer 7

There are already some great answers, but I'll add my own, very simple answer: Start at the beginning. Whatever the user will see first.

If you start with something like a configuration/admin interface, you run the risk of spending a lot of time writing code to configure systems that ultimately never actually get implemented. By starting on user-visible features, you can get something out there, and make some use of it. That experience almost always helps keep mental momentum up, and also inspires new idea that you wouldn't have thought of in a completely abstract, unimplemented design. At any step, always try to have the most useful subset possible.