The Garage Architecture

After a couple of weeks break, we’re back to our architecture series. This time we’ll look at something I’ve recently come up with – The Garage Architecture!


I’ve been recently working on a pet project at home, playing with the all-cool Ionic 2 framework and I came to the point in which I wanted to create some sort of back-end for my app. For some reason, the mere thought of building a full-blown layered/hexagonal application made me feel bad. I was heavily thinking about using the DB directly with PouchDB or using a “backendless” solution like Firebase. To cut the storytelling before everyone leaves, I wondered why as a “true” back-end developer do I even look towards those “fake” solutions and feel some sort of disgust for doing the work myself. My conclusion: pet projects require a different approach than the enterprise ones!

Theory of Pet Projects

Dev #1: I have a ton of million dollar ideas. If only I sat down and took the time to develop them… I’d be so rich!

Dev #2: Yeah, me too!

Dev #3: And all the thousands of other software developers around the world. Don’t bother starting, the excitement will stop soon and you won’t finish it anyway.

The quote above is part of a real conversation I’ve once had in a corporate kitchen. I honestly don’t remember if I said any of these or I was just listening but it stuck in my mind because it seemed so true. Every single project I have ever started at home sooner or later ended up killed with an excuse of it wouldn’t work out anyway, the idea was too bad.

If you’re like me in the continuous process of starting and giving up, or you’re like thousands of others who don’t even start and keep waiting for the fantastic, glorious idea that will excite the world and bring you billions of dollars, let me tell you two extremely important things:

  1. The brilliant idea will never come because it doesn’t exist.
  2. What counts instead is the EXECUTION.

Anything that was ever created in this world was either a copy, minor improvement or a new combination of what have already existed. Pick any successful computer application ever built and with enough research, you will come to the conclusion that they didn’t invent anything new, they just improved an existing idea or simply executed it better. Were there no operating systems before MS-DOS? Were there no video players before YouTube? Were there no social apps before Facebook? You get the point.

Principles of Garage Architecture

Now that you understand my background and thoughts about pet projects, you will have an easier time understanding my point of view. I want to maximize the chance that once somebody comes up with a pet project idea, he actually finishes the project and the final output is good enough to make it a success (and he later tells stories how he created a million dollar product in his garage). Based on all of the above, all my knowledge, and my pet project (failure) experience, I came up with the following 5 principles:

  1. Garage Architecture has to be fun i.e. it has to feel like you’re doing your hobby rather than working extra hours each week.
  2. It has to help you produce results as fast as possible so that you get encouraged by the progress rather than discouraged by its lack.
  3. It has to be cutting-edge in a way that lets you bring the best possible experience to potential customers.
  4. It has to be educative so that even if the project failed, you would say At least I learned something!
  5. It has to be throw-away-able. If your project becomes a rapid success, you will surely see how many things you did not account for. Don’t get yourself emotionally attached to it and don’t let the code be too attached to itself.

My Garage Architecture

It should be obvious now that Garage Architecture is more of an idea than any particular solution. The actual implementation will depend on the programming languages and architectures (including technologies) you know, use at work, and want to learn in the nearest future. More generally speaking, it will depend on YOU. Now, I ain’t a mind reader and this blog serves relatively static content and so I won’t be able to tell you how your Garage Architecture should look like. But I can tell you a bit about how mine looks like. Here we go.

Front-End – Ionic 2

As I’ve told you in the Background section, I was playing with Ionic 2, which is basically Angular 2 on steroids that help it look good on all kinds of devices without much developer intervention. Since I’m a full-time back-end developer at Zooplus and my blog is mostly about Java, I obviously don’t have the skills and time to build nicely looking applications for each device myself. Hence, Ionic 2 seemed like a good compromise.

Working with it is pleasant, it allows me to build web and mobile applications at the same time and the app’s experience is close enough to native, at least for a beginner like me. That covers principles of fun, fast results, and cutting-edge.  As I mentioned, I’m not really skilled in this stuff so I’m learning a lot, hence the principle of education is also on my side. To cover principle of throw-away-ability, I decided to build the back-end myself, so that I’m not limited in any way when replacing front-end clients e.g. with native mobile applications or when willing to switch databases.

Back-End – Vert.x

For the back-end, I chose Vert.x as I’ve already started learning the framework and had some fun with it when writing the post about Reactive Clean Architecture. But this time, as opposed to the stuff in the linked article, I will be writing the thinnest, most direct code possible. No interfaces, no working around frameworks, no extraneous layers of abstraction. There will be 2 conceptual layers: endpoints and entities. The former should cover all the non-domain behavior of an endpoint, while the latter would contain domain rules. I haven’t implemented too much yet, so I don’t know if the “repositories” will be needed. Even if so, I won’t call them repositories. I want the system as de-enterprised as possible so that it does not remind me of work in any way.

Maybe one day I’ll share a bigger example of my Garage Architecture implementation, but so far, I have done only a simple PoC analogous to the example in Reactive Clean Architecture. It takes a list of activities and displays it but this time in JSON format, consumable by my Ionic 2 application. The directory structure looks like this:

Garage Architecture built with just 2 packages - endpoints and entities

The only interesting class in this project is  ListActivities. It makes a dedicated SQL query that produces a result ready to be returned as a JSON response from the service. In the PoC it uses callbacks, but I will probably switch to RxJava in the actual project.

Consciously avoiding the layering and de-enterprising my architecture makes me feel like a little home hacker again (fun). By making the code as direct and straightforward as possible, I hope to develop things way faster than I’d normally would (fast results). Playing with reactive technologies like Vert.x and (hopefully) RxJava is educative and cutting-edge at the same time. Once the project grows, I’ll try to split things into microservices, so that it doesn’t bite me in case I had to rewrite some functionality to something more flexible or more testable. And I obviously won’t get attached to this non-Tidy code, so I’ll be more than happy to rewrite it bit by bit once the pet project becomes a viable product (throw-away-ability).

Your Garage Architecture

Enough talking about me. Now it’s your turn! Take your pet project ideas out of your brain, notebook or wherever you keep them and start working. Identify, what makes you most annoyed in your daily work and do exactly the opposite. Don’t be afraid of doing something dirty (in the programming sense!). Find out some cutting-edge technologies that will allow you to quickly produce a lot of value, and learn some new things at the same time. And start producing the code making it good enough for a valuable product but not perfected enough to get too attached. Let’s finish with a paraphrase of the old WoW commercial slogan: What’s Your Garage Architecture?

About the Author Grzegorz Ziemoński

King of Tidy Java, nerd that thinks about producing perfect software all the time and proud owner of 2 cats.

follow me on:
  • cblin

    I was in the same situation as you (backend (java/.NET) dev) and draw the same conclusions : fun, educative, fast results, throwable.

    I really like your definition of garage architecture.

    My garage architecture is
    mobile frontend : Ionic (1.3 because 2 was not available)
    backend : sparkjava (because it’s indeed a no framework approach) and postgres
    PaaS : heroku

    If I wanted to start a new project right now, I will not use vert.x but serverless as it seems funnier and faster to host in the web.

    • Ha! It’s funny how two different people with different backgrounds can reach conclusions and architectures this similar. How’s your project going? Any public releases so far?

      • cblin

        in fact, after a public release on the app store and too few downloads, the project is now dead 🙂

        the idea was not bad but the fun has gone like the educative part 🙂

        hope your project will not suffer the same faith !