dbFront excels in the ability to quickly and economically bring simple web applications to life. The primary trade-off is that dbFront intentionally lacks the ability for deep customization. This means that systems created using dbFront quickly get you to a point of good enough with the hope that this is good enough.
Below we will look at the categories of web applications for which dbFront is uniquely suited.
One of the specific voids that dbFront attempts to fill is as a tool for those applications that would otherwise never be built:
- the applications for which there is insufficient ROI,
- the applications for which there is insufficient budget,
- the applications that are needed now and not later.
Most businesses are willing to spend a day on an idea that looks promising but beyond that serious budgeting considerations need to be worked through. All of the above application categories are ideal candidates for dbFront because with dbFront it can only take about 30 minutes or less to stand up a web application based on an existing database. This means that it is feasible for a DBA or Analyst to:
- have a conversation with a client,
- cobble together an initial ERD,
- build a database and finally,
- show the client a working application using dbFront before the day is over.
Even better, because dbFront builds it's UI dynamically, there is every opportunity to continue building on the initial database structure in an iterative fashion.
Because the licensing, capital costs and development time with dbFront are so low, systems that would have been considered impractical are now possible.
In addition, even if it is determined that dbFront is not a good final tool, then little is lost because all of the analysis and design can be carried forward into the final solution. In this case dbFront would have served the purpose of a uniquely functional prototyping tool.
Lots of effort is is spent creating web applications that can respond reasonably to anticipated business changes. This is because changing applications in mid stream is risky and expensive.
dbFront is intentionally designed to make many common changes trivial. Creating, changing or removing fields. Adding new relationships, moving fields around. dbFront takes all of these changes and more in stride and does its best to reuse any preferences you might have previously saved.
Sometimes you just have no idea what the final solution will look like. You just know that you have data you want to collect or maintain.
In those cases, start with what you know and add the rest as you gain a better idea of what needs to be done.
Where dbFront is not suitable
- If your data structure is not Third Normal Form.