I built nderground using Grails. The development of Grails was inspired by the idea of providing a framework like Ruby on Rails for the Java ecosystem (the major language used in Grails development is Groovy, a language derived from Java).

Like Rails, Grails has a model-view-controller architecture. Grails also adds services, which are a layer that can be used to provide services that are not directly related to managing user interaction. This includes support for DynamoDB, Amazon S3 storage and email. I use the Grails Hibernate layer to access Amazon RDS/Postgres.

Grails has been a critical resource for building nderground. Grails and the Eclipse based GGTS IDE allow me to move smoothly between client side and server side code. So no regrets.

nderground is a monolithic application, deployed as a large web archive (.war) file, on Amazon’s Elastic Beanstalk.

I agree that it would be a bad idea to try to break nderground up into microservices at this point. For the foreseeable future, a monolithic architecture structured around Grails is the best course.

I can imagine the monolithic structure of nderground becoming a problem at some point in the future. Although the architecture is divided into domains (the RDS/Postgres database tables), controllers and services and these have defined interfaces, there is no avoiding the fact that the code is intertwined. For example, some services, like those that provide information about access permission, are used throughout the code base.

If nderground were to grow to the size of Basecamp, with a development team of 12 people, I think that I would consider ways to make the code base independent. Labeling a huge monolithic code base a “Majestic monolith” seems to be describing a potential problem as a virtue.