In my current role as a software developer in a Java/Spring/Hibernate/JSF shop, I am sometimes asked to develop large-scale web apps with many interfacing systems and/or large databases as well as small-scale web apps with low traffic and/or simple databases. To accommodate this variation, I would like to have 2 technology stacks to choose from, depending on the type of application I'm asked to develop. I think this would benefit us because I think our technology stack that I mentioned above is a bit over-engineered or cumbersome for small, simple CRUD applications.

If, for example, I have chosen Spring Framework for my large-scale apps and Play! Framework for my small-scale apps, how do I choose which one to use for a given application? In other words, how can I tell if a proposed web application qualifies for a heavy framework like Spring or could stand to benefit more from a lightweight, agile framework like Play?

Can someone give me some rough checkpoints to help me decide which type of framework to use (heavy or light)? If you use this two-framework approach, please tell me what criteria you use to decide which framework is the best fit for a given web application.

  • spring-boot / spring-jpa is rather light weight, at least from the developer and configuration perspective. You should try it out.
    – ASA
    Sep 26, 2016 at 11:38

1 Answer 1


Indeed a full scale Java/Spring/Hibernate/JSF implementation may be a bit too engineered for the requirements of many small scale systems, however I typically evaluate new application requirements on the following factors to help myself determine the appropriate architecture:

Anticipated User Load

  • What is the anticipated user load?
  • Are there potentially an enormous amount of users?
  • Are the users performing tasks that will utilize high amounts of resources?
  • Will the application need to scale horizontally with increased load?

Anticipated Future Scope

This one is hard to judge sometimes because the scope can sometimes be at the whim or will of a product manager or sales person. If you anticipate that there is even the smallest possibility that a salesperson could try to brand it and sell it to anybody other than the original stakeholders then it is probably best to go with a more layered approach.

Distributed System Needs

Are there any anticipated needs for various differing consumers to achieve different information in different ways (Mobile app, ETL, SSO, public web services, etc...) then you always want to have a three tier distribution approach and have logical seperation of components and layers. These types of architectural requirements will be better served by a more engineered approach.

Budget Constraints

What is the allocated budget for hosting the application in production? Will it require expensive proprietary software licenses, multiple VPS's, high availability cloud computing? Perhaps if you are only allowed a limited budget then CHEAP hosting technologies like PHP may make a lot more sense.

Knowledge Constraints

What is your team more efficient in implementing? What are their skills and weaknesses. Sure Play Framework may look cool for rapid application development, however if there is a significant learning curve there then perhaps you take less risk in the more cumbersome over-engineered approach that is well understood.

Time Constraints

How much time do you have to develop the application. This also plays into Knowledge Constraints as time needed to learn a new technology can be an imposition on time.

  • 1
    Good checklist. Time constraints have been one of the biggest things for me. When you only have a few days to implement a new web site, sometimes using something pre-built, like WordPress or Sharepoint, is the best solution. More custom solutions where time isn't as big an issue are more open to MVC frameworks.
    – jfrankcarr
    Feb 25, 2013 at 22:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.